<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 28, 2014 at 4:31 PM, Stephen Kelly <span dir="ltr"><<a href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Stephen Kelly wrote:<br>
<br>
> To "fix" that, I created this module.modulemap in /usr/include :<br>
><br>
> module systemheaders {<br>
> header "stdio.h"<br>
> header "stdlib.h"<br>
> header "math.h"<br>
> }<br>
><br>
> After I did that, I was able to create a Qt5Core.modulemap on linux. I<br>
> expect that file to grow if I add more modules for other Qt libraries.<br>
<br>
</span>The Qt headers include very few external headers. Apart from the QtTest<br>
module, it's only a few STL headers, and platform-specific opengl headers.<br>
<br>
In order to be able to build the Qt5Test.modulemap, I had to extend the file<br>
I hacked together in /usr/include/module.modulemap like so:<br>
<br>
 module system {<br>
<span class="">   header "stdio.h"<br>
   header "stdlib.h"<br>
   header "math.h"<br>
</span>   module system_c [extern_c] {<br>
     header "inttypes.h"<br>
   }<br>
 }<br>
<br>
<br>
If I keep going like this, my /usr/include/module.modulemap will refer to<br>
headers which come from different debian packages. This seems unacceptable<br>
to me, but you'd have to talk to some packagers to make sure. (for modules<br>
to be viable on linux, I'm sure you have to somehow solve the system headers<br>
case or make it solvable).<br></blockquote><div><br></div><div>You might want to try using the `extern module foo "foo.modulemap"` syntax in the root module map. This doesn't solve the installation problem, but it might simplify things for now. I think that the typical package-based Linux platform (with end-users installing and uninstalling headers into the same directories) is currently a poorly-represented use case. If you can find a system that seems to work well for that use case in practice, I think we would take a patch to support it; unfortunately I don't think there is anybody working on modules right now that has this use case as a priority, so it really is "patches welcome".</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So, a solution would be to use the new mechanism to specify multiple module<br>
map files. However, it would be unsatisfying to have to specify many<br>
<br>
 /usr/include/{foo,bar,bat}.modulemap<br>
<br>
files using -fmodule-map-file, because it is a system location. I can easily<br>
think of some options for improving that situation, and I'm sure there are<br>
more options:<br>
<br>
1) Add option to give the clang driver a module map directory<br>
<br>
Then packages would install their modulemap to a well-known location and all<br>
modulemaps in that location would get loaded<br>
<br>
 ${prefix}/modulemaps/{foo,bar,bat}.modulemap<br>
<br>
and<br>
<br>
 clang -fmodules -fmodule-map-dir=${prefix}<br>
<br>
loads all module maps in ${prefix}.<br>
<br>
This solution has the disadvantage that authors would have to write<br>
<br>
 header "../foo.h"<br>
<br>
and similar, unless clang had built-in logic to look up a directory.<br>
<br>
System locations should be built-in without being specified, so I never have<br>
to write<br>
<br>
 -fmodule-map-dir=/usr/include/modulemaps<br>
<br>
or anything. Maybe clang should automatically look in ${dir}/modulemaps for<br>
each -I${dir} passed on the command line (and each built-in dir) and load<br>
any modulemaps found in those directories.<br>
<br>
<br>
2) Clang could load *.modulemap, not only module.modulemap from each dir<br>
<br>
This seems like a simple solution and doesn't require '..' paths.<br>
<br>
<br>
3) Files in ${dir}/modulemaps/* are redirects to '..'<br>
<br>
Ie, packages would install<br>
<br>
 /usr/include/foo.modulemap<br>
 /usr/include/foo.h<br>
 /usr/include/modulemaps/foo.redirect<br>
<br>
and foo.redirect would contain some syntax to make clang behave as if<br>
<br>
 -fmodule-map-file=/usr/include/foo.modulemap<br>
<br>
was passed. Eg, foo.redirect might contain only<br>
<br>
 ../foo.modulemap<br>
<br>
and then foo.modulemap would not need '..' paths.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Thanks,<br>
<br>
Steve.<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>