Thanks Argyrios. Richard & Dmitri: just to confirm - are you okay with me committing this now, or did either of you intend to review the patch first?
Ben On Mar 17, 2014, at 11:17 PM, Argyrios Kyrtzidis <[email protected]> wrote: > LGTM! > > On Mar 17, 2014, at 3:30 PM, Ben Langmuir <[email protected]> wrote: > >> Updated patch attached that switches the preferred spelling to >> ‘module.modulemap’ and also updates docs/Modules.rst. >> >> Ben >> >> <modulemap.patch> >> >> >> On Mar 17, 2014, at 2:23 PM, Ben Langmuir <[email protected]> wrote: >> >>> >>> On Mar 17, 2014, at 1:44 PM, Richard Smith <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>> <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> _______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
