<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/19/2017 07:08 AM, Manuel Klimek
wrote:<br>
</div>
<blockquote
cite="mid:CAOsfVvnm7XRZFVQKD01fj5-_2wkUj85CvtWYBG1gnDo+ziW4=w@mail.gmail.com"
type="cite">
<div dir="ltr">
<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"> 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><br>
</div>
<div>You can have /usr/include/<name>.modulemap if you
want. Your build system just will need to support that.</div>
</div>
</div>
</blockquote>
<br>
So,<br>
<br>
* We rely on library authors knowing to do that (how would they find
out, given that clang documentation doesn't recommend it?)<br>
* 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>
* 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.<br>
<br>
<blockquote
cite="mid:CAOsfVvnm7XRZFVQKD01fj5-_2wkUj85CvtWYBG1gnDo+ziW4=w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>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>
They won't just 'pick up' the right flags by magic right? Or am I
missing something?<br>
<br>
<blockquote
cite="mid:CAOsfVvnm7XRZFVQKD01fj5-_2wkUj85CvtWYBG1gnDo+ziW4=w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>The current implementation of automatic detection of
module maps is completely driven by the original Obj-C use
cases.</div>
<div>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>
That doesn't seem to be what clang documents as the preferred way to
use the feature. Eg, "The
<code class="docutils literal"><span class="pre">module.modulemap</span></code>
file is placed alongside the header files themselves" ie,
`/usr/include/module.modulemap`<br>
<br>
<a class="moz-txt-link-freetext" href="http://clang.llvm.org/docs/Modules.html">http://clang.llvm.org/docs/Modules.html</a><br>
<br>
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>
<br>
Thanks,<br>
<br>
Steve.<br>
<br>
</body>
</html>