[cfe-dev] [Modules TS] Have the file formats been decided?

[Stephen Kelly via cfe-dev]

On 01/19/2017 07:08 AM, Manuel Klimek wrote:
>
>     The bug report links to a mailing list thread. Does that provide
>     more context? IOW: Why make
>
>      /usr/include/module.modulemap
>
>     contended by everything that installs into /usr ? Was a solution
>     of uncontended
>
>      /usr/include/<name>.modulemap
>
>     considered and discarded? Why?
>
>
> You can have /usr/include/<name>.modulemap if you want. Your build
> system just will need to support that.

So,

* We rely on library authors knowing to do that (how would they find
out, given that clang documentation doesn't recommend it?)
* 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.
* 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.

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

They won't just 'pick up' the right flags by magic right? Or am I
missing something?

> The current implementation of automatic detection of module maps is
> completely driven by the original Obj-C use cases.
> 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!).

That doesn't seem to be what clang documents as the preferred way to use
the feature. Eg, "The |module.modulemap| file is placed alongside the
header files themselves" ie, `/usr/include/module.modulemap`

 http://clang.llvm.org/docs/Modules.html

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.

Thanks,

Steve.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170121/75042a79/attachment.html>