r250577 - [modules] Allow the error when explicitly loading an incompatible module file

[Manuel Klimek via cfe-commits]

On Tue, Oct 20, 2015 at 3:38 PM Brad King <brad.king at kitware.com> wrote:

> On 10/20/2015 04:38 AM, Manuel Klimek wrote:
> > On Tue, Oct 20, 2015 at 5:52 AM Sean Silva wrote:
> >> get cmake to generate clang module map files and add explicit module
> build steps?
> >
> > I have some experience hacking on cmake, and from my experience I think
> > this shouldn't be too hard to get working (mainly work ;)
>
> I agree this shouldn't be too hard on the CMake side.  Manuel, please
> come over to the cmake dev list to raise the design discussion.  Then
> we can guide your implementation work.


I think Sean volunteered :) (but please keep me cc'ed if you start
discussing this on cmake-dev)


>   The main design challenges
> I foresee are:
>
> 1. Deciding how this behavior should be activated for a project by
>    its code and/or by the user.
>
> 2. Selection of the proper set of headers if it is not exactly the set
>    listed in the target for some reason.  Might this ever by more
>    granular than a whole library target?
>

I don't think so.
Main concerns are:
1. we need to be able to say something is a "textual" header; those are
still needed; we can do that by calling them .inc, or by putting something
into cmake to specify textual headers (that's what we do in our build
system)
2. for the "slow rollout" case we use per-header submodules; but that's
more an implementation detail than anything else, I think


>
> 3. Finding the right place during the CMake generation process to add
>    the rules for this.
>
> We already detect the Clang compiler version so deciding if it is
> new enough to support the feature should not be hard.
>
> Thanks,
> -Brad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151020/dbff38b9/attachment.html>