Add a new spelling for module map files 'module.modulemap'

[Ben Langmuir]

Updated patch attached that switches the preferred spelling to ‘module.modulemap’ and also updates docs/Modules.rst.

Ben




On Mar 17, 2014, at 2:23 PM, Ben Langmuir <blangmuir at apple.com> wrote:

> 
> On Mar 17, 2014, at 1:44 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 
>> I don't think the extra stat calls are a meaningful cost -- most of the time, none of the files will be present, so we'll perform all four (failed) stats, so if they *are* significant, we have bigger problems…
> 
> Good point.
> 
>> 
>> The old/new default only affects cases where both files are provided (which is a clear sign that the project is trying to be compatible with both the old and the new form). In such cases, it seems to me that we should pick the newer file -- that way, when we come to turn off support for the old names, we won't introduce a change in behavior.
> 
> Okay I buy this.  I’ll prefer the new spelling.
> 
>> 
>> I'm not overly concerned about the warning. I think most affected people would be Xcode Clang users, so you guys should do whatever works best for you to transition your existing modules users.
> 
> Hmm, after changing to prefer the new spelling, I’m not sure this is interesting enough anymore.  My primary concern was that we might accidentally hide errors in module.modulemap files by having stray module.map files around.
> 
> Thanks,
> 
> Ben
> 
>> 
>> On Mon, Mar 17, 2014 at 1:26 PM, Ben Langmuir <blangmuir at apple.com> wrote:
>> That is the direction I would like to go eventually, but I didn't want to deprecate the old spelling in the short term, since we still have lots of module.map files that would need to be moved. The advantage of checking for the old name first is that we save stat calls by looking for the more likely to hit name first.
>> 
>> Ben
>> 
>> On Mar 17, 2014, at 11:56 AM, Richard Smith <richard at metafoo.co.uk> wrote:
>> 
>>> I have no objection to the name change.
>>> 
>>> It seems that the intent is to move away from the old module.map name entirely. That being the case, should we look for the new name first, and consider adding a warning if we find the old name?
>>> 
>>> On Mon, Mar 17, 2014 at 11:33 AM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
>>> + Richard.
>>> 
>>> Do you have an objection to what Ben proposes here ? The “.map” extension is unfortunate and we’d really like to move “.modulemap”; the best chance to change it is now, before first class support for user modules enters the picture.
>>> 
>>> On Mar 17, 2014, at 10:40 AM, Ben Langmuir <blangmuir at apple.com> wrote:
>>> 
>>> >    This name, while more verbose, plays more nicely with tools that use
>>> >    file extensions to determine file types. The existing spelling
>>> >    'module.map' will continue to work, and at least for now will take
>>> >    precedence if both files exist within a directory. In a future patch, I
>>> >    intend to add a warning for when both files could be found.
>>> >
>>> >    In frameworks, this new filename will only go in a new 'Modules'
>>> >    sub-directory.
>>> >
>>> >    Similarly, add a module.private.modulemap corresponding to
>>> >    module_private.map.
>>> >
>>> > <modulemap.patch>
>>> 
>>> 
>> 
>> 
> 
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140317/47af4672/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: modulemap.patch
Type: application/octet-stream
Size: 22853 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140317/47af4672/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140317/47af4672/attachment-0001.html>