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

[Manuel Klimek via cfe-dev]

On Sat, Jan 21, 2017, 1:31 PM Stephen Kelly <steveire at gmail.com> wrote:

> 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?)
>

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.

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

I'd have hoped most would call them name.modulemap

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

Yep. Modules fundamentally change the C++ build, so I don't see a way that
wouldn't require putting support into build systems.
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.


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

Build system support is needed. This is not very different from the current
state where many libraries you use require specific flags to build.


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

All this is in no way decided. Modules are still in the early stages. I
have no idea when they'll be standardized.

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.

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.


> Thanks,
>
> Steve.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170122/767669b0/attachment.html>