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

Sean Silva via cfe-commits cfe-commits at lists.llvm.org
Tue Oct 20 14:11:47 PDT 2015

On Tue, Oct 20, 2015 at 6:45 AM, Manuel Klimek <klimek at google.com> wrote:

> 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

What is the "slow rollout" case?

-- Sean Silva

>> 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/fd3421ba/attachment.html>

More information about the cfe-commits mailing list