<br><br><div class="gmail_quote"><div dir="ltr">On Sat, Jan 21, 2017, 1:31 PM Stephen Kelly <<a href="mailto:steveire@gmail.com">steveire@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
<div class="m_-635234131964010664moz-cite-prefix gmail_msg">On 01/19/2017 07:08 AM, Manuel Klimek
wrote:<br class="gmail_msg">
</div>
<blockquote type="cite" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div class="gmail_quote gmail_msg">
<blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000" class="gmail_msg"> The
bug report links to a mailing list thread. Does that
provide more context? IOW: Why make <br class="gmail_msg">
<br class="gmail_msg">
/usr/include/module.modulemap <br class="gmail_msg">
<br class="gmail_msg">
contended by everything that installs into /usr ? Was a
solution of uncontended<br class="gmail_msg">
<br class="gmail_msg">
/usr/include/<name>.modulemap <br class="gmail_msg">
<br class="gmail_msg">
considered and discarded? Why?<br class="gmail_msg">
</div>
</blockquote>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">You can have /usr/include/<name>.modulemap if you
want. Your build system just will need to support that.</div>
</div>
</div>
</blockquote>
<br class="gmail_msg"></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
So,<br class="gmail_msg">
<br class="gmail_msg">
* We rely on library authors knowing to do that (how would they find
out, given that clang documentation doesn't recommend it?)<br class="gmail_msg"></div></blockquote></div><div><br></div><div>This is going to become a priority going forward, but it hasn't been yet. Specifically, we'll need to discuss this in more detail, and carefully design it, optimally pulling in as many stakeholders as we can.</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
* Library authors won't automatically name things consistently, so
we will also get libraries with <name>lib.modulemap and
lib<name>.modulemap and doubtless other variations.<br class="gmail_msg"></div></blockquote></div><div><br></div><div>I'd have hoped most would call them name.modulemap</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
* It would be preferable to have the buildsystem hide that detail,
if it must exist. That would be possible with cmake usage
requirements, but most libraries don't install cmake config files,
and consumers don't necessarily use cmake anyway. I guess other
buildsystems would have a similar issue.</div></blockquote></div><div><br></div><div>Yep. Modules fundamentally change the C++ build, so I don't see a way that wouldn't require putting support into build systems.</div><div>Both with autotools and cmake you usually call an installed function to detect a library, which will give you the flags you need to compile it. Those will need to change for a library wanting to be compiled as a module.</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
<blockquote type="cite" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div class="gmail_quote gmail_msg">
<div class="gmail_msg">You can even put your module map in /usr/lib or wherever
else other parts of your library are going to be installed
in, as long as build systems will pick up the right flags to
compile your library with.</div>
</div>
</div>
</blockquote>
<br class="gmail_msg"></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
They won't just 'pick up' the right flags by magic right? Or am I
missing something?</div></blockquote></div><div><br></div><div>Build system support is needed. This is not very different from the current state where many libraries you use require specific flags to build.</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
<blockquote type="cite" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div class="gmail_quote gmail_msg">
<div class="gmail_msg">The current implementation of automatic detection of
module maps is completely driven by the original Obj-C use
cases.</div>
<div class="gmail_msg">For C++, I don't expect that we will use that mechanism,
much for the reasons you cite. My hope is that we'll go into
a world where we explicitly specify the module maps on the
command line (less magic!).</div>
</div>
</div>
</blockquote>
<br class="gmail_msg"></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
That doesn't seem to be what clang documents as the preferred way to
use the feature. Eg, "The
<code class="m_-635234131964010664docutils m_-635234131964010664literal gmail_msg"><span class="m_-635234131964010664pre gmail_msg">module.modulemap</span></code>
file is placed alongside the header files themselves" ie,
`/usr/include/module.modulemap`<br class="gmail_msg">
<br class="gmail_msg">
<a class="m_-635234131964010664moz-txt-link-freetext gmail_msg" href="http://clang.llvm.org/docs/Modules.html" target="_blank">http://clang.llvm.org/docs/Modules.html</a><br class="gmail_msg">
<br class="gmail_msg">
There would need to be a change in emphasis there at least to change
things to your vision. I'm not convinced it can work. It seems to
make the feature not suitable for widespread adoption.
Maybe/hopefully I'm missing something though. <br class="gmail_msg"></div></blockquote></div><div><br></div><div>All this is in no way decided. Modules are still in the early stages. I have no idea when they'll be standardized.</div><div><br></div><div>A final note: without build system integration and changes to your code structure, modules are likely to make your incremental builds slower. Apple has some experience here, see Daniel Dunbar's talk at the llvm dev meeting.</div><div><br></div><div>If you think non zero effort will make people not use them, then they'll not use them. I don't think that's bad, it's an effort vs payout trade-off.</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
<br class="gmail_msg">
Thanks,<br class="gmail_msg">
<br class="gmail_msg">
Steve.<br class="gmail_msg">
<br class="gmail_msg">
</div>
</blockquote></div>