[cfe-dev] How do I try out C++ modules with clang?

[Sean Silva]

On Tue, Oct 28, 2014 at 4:31 PM, Stephen Kelly <steveire at gmail.com> wrote:

> Stephen Kelly wrote:
>
> > To "fix" that, I created this module.modulemap in /usr/include :
> >
> > module systemheaders {
> > header "stdio.h"
> > header "stdlib.h"
> > header "math.h"
> > }
> >
> > After I did that, I was able to create a Qt5Core.modulemap on linux. I
> > expect that file to grow if I add more modules for other Qt libraries.
>
> The Qt headers include very few external headers. Apart from the QtTest
> module, it's only a few STL headers, and platform-specific opengl headers.
>
> In order to be able to build the Qt5Test.modulemap, I had to extend the
> file
> I hacked together in /usr/include/module.modulemap like so:
>
>  module system {
>    header "stdio.h"
>    header "stdlib.h"
>    header "math.h"
>    module system_c [extern_c] {
>      header "inttypes.h"
>    }
>  }
>
>
> If I keep going like this, my /usr/include/module.modulemap will refer to
> headers which come from different debian packages. This seems unacceptable
> to me, but you'd have to talk to some packagers to make sure. (for modules
> to be viable on linux, I'm sure you have to somehow solve the system
> headers
> case or make it solvable).
>

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".

-- Sean Silva


>
> So, a solution would be to use the new mechanism to specify multiple module
> map files. However, it would be unsatisfying to have to specify many
>
>  /usr/include/{foo,bar,bat}.modulemap
>
> files using -fmodule-map-file, because it is a system location. I can
> easily
> think of some options for improving that situation, and I'm sure there are
> more options:
>
> 1) Add option to give the clang driver a module map directory
>
> Then packages would install their modulemap to a well-known location and
> all
> modulemaps in that location would get loaded
>
>  ${prefix}/modulemaps/{foo,bar,bat}.modulemap
>
> and
>
>  clang -fmodules -fmodule-map-dir=${prefix}
>
> loads all module maps in ${prefix}.
>
> This solution has the disadvantage that authors would have to write
>
>  header "../foo.h"
>
> and similar, unless clang had built-in logic to look up a directory.
>
> System locations should be built-in without being specified, so I never
> have
> to write
>
>  -fmodule-map-dir=/usr/include/modulemaps
>
> or anything. Maybe clang should automatically look in ${dir}/modulemaps for
> each -I${dir} passed on the command line (and each built-in dir) and load
> any modulemaps found in those directories.
>
>
> 2) Clang could load *.modulemap, not only module.modulemap from each dir
>
> This seems like a simple solution and doesn't require '..' paths.
>
>
> 3) Files in ${dir}/modulemaps/* are redirects to '..'
>
> Ie, packages would install
>
>  /usr/include/foo.modulemap
>  /usr/include/foo.h
>  /usr/include/modulemaps/foo.redirect
>
> and foo.redirect would contain some syntax to make clang behave as if
>
>  -fmodule-map-file=/usr/include/foo.modulemap
>
> was passed. Eg, foo.redirect might contain only
>
>  ../foo.modulemap
>
> and then foo.modulemap would not need '..' paths.
>
>
> Thanks,
>
> Steve.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141031/c57e9ee1/attachment.html>