On Thu, 10 Jan 2019 at 23:17 Ben Craig <ben.craig_at_[hidden]> wrote:

> I’m not a fan of the MANIFEST / module map approach in general. It
> requires duplicating information that is already in the source. I get that
> it has the potential to speed up builds, but I’d rather not have to update
> another location when I add a new .cpp file to my project. Many build
> systems allow for the user to make the tradeoff in whether they will use a
> file system glob to enumerate their source, or require the user to list the
> source manually. I usually fall into the file system glob crowd.
>
>
+1
I think the less files we have to describe the build, the easier to
maintain it is.



>
>
> *From:* tooling-bounces_at_[hidden] <tooling-bounces_at_[hidden]> *On
> Behalf Of *Gabriel Dos Reis
> *Sent:* Thursday, January 10, 2019 3:15 PM
>
>
> *To:* WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
> *Subject:* Re: [Tooling] Modules naming
>
>
>
> Microsoft strongly encourages its developers and customers to NOT tie a
> module name with the containing source file of its interface. This is
> based on decades of experience caused by header files. I would rather see
> us move in the direction of some sort of MANIFEST file that map modules to
> source files and artifacts.
>
>
>
> *From:* tooling-bounces_at_[hidden] <tooling-bounces_at_[hidden]> *On
> Behalf Of *Corentin
> *Sent:* Thursday, January 10, 2019 6:53 AM
>
>
> *To:* WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
>
> *Subject:* [Tooling] Modules naming
>
>
>
> Hello.
>
> I would like to suggest two modules related proposals that I think SG15
> should look at.
>
>
>
> -* Compiler enforced mapping between module names and module interface
> file (resource) name. *
>
>
>
> Currently, modules interfaces can be declared in any file - which makes
> dependency scanning more tedious than it needs to be and have performance
> implications
>
> (The build system needs to open all files to gather a list of modules) -
> notably when the build system tries to start building while the dependency
> graph isn't yet complete.
>
>
>
> Tools ( ide, code servers, indexers, refactoring) may also greatly benefit
> from an easier way to locate the source file which declares a module.
>
>
>
> The specifics of the mapping are open to bikeshedding. However, I think we
> would have better luck sticking to something simple like <module
> identifier> <=> <file name>.<extension>
>
> (The standardese would mention *resource identifier* rather than filename)
>
>
>
> - *A standing document giving guidelines for modules naming.*
>
>
>
> The goal is to take everything the community had to learn the hard way
> about header naming over the past 30 years and apply it to modules by
> providing a set of guidelines
>
> that could be partially enforced by build system vendors.
>
> Encouraging consistency and uniqueness of module identifiers across the
> industry is I think a necessary step towards sane package management.
>
> Note that the standard requires uniqueness of modules identifiers within
> (the standard definition of) a program but says little about a way to
> ensure this uniqueness.
>
>
>
> Here is a rough draft of what I think would be good guidelines, partially
> inspired by what is done by other languages facing similar issues.
>
> · *Prefix module names with an entity and/or a project name to
> prevent modules from different companies, entities and projects of
> declaring the same module names.*
>
> · *Exported top-level namespaces should have a name identic to
> the project name used as part of the name of the module(s) from which it is
> exported.*
>
> · *Do not export multiple top-level namespaces*
>
> · *Do not export entities in the global namespace outside of the
> global module fragment.*
>
> · *Organize modules hierarchically.* For example, if both modules
> example.foo and example.foo.bar exist as part of the public API of example
> , example.foo should reexport example.foo.bar
>
> · *Avoid common names such as *util* and *core* for module name
> prefix and top-level namespace names.*
>
> · *Use lower-case module names*
>
> · *Do not use characters outside of the basic source character
> set in module name identifiers.*
>
> My hope is that these 2 proposals (whose impact on the standard is
> minimal) would make it easier for current tooling to deal with modules
>
> while making possible for example to design dependency managers and build
> systems able to work at the module level.
>
>
>
> I'd love to gather feedback and opinions before going further in that
> direction.
>
> Thanks a lot!
>
>
>
> Corentin
>
>
>
> PS: For a bit of background, I talked about these issues there
>
>
>
> https://cor3ntin.github.io/posts/modules_mapping/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fcor3ntin.github.io-252Fposts-252Fmodules-5Fmapping-252F-26data-3D02-257C01-257Cgdr-2540microsoft.com-257C1139eb25a2ca43b5cb2e08d6770b6606-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636827288180838903-26sdata-3DRbCelyBe1YDW4eNJtYEgKkAeHGxvkhsYqzPk0wf3F58-253D-26reserved-3D0&d=DwMGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=Yv6fjy4yWnfBkW_0m604prnwiQIO5K6DRLBHMjpiaxI&s=v7Z40T9WgivvxWUJ6plSphOw4d8bdvfEz9NAqCruKwE&e=>
>
> https://cor3ntin.github.io/posts/modules_naming/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fcor3ntin.github.io-252Fposts-252Fmodules-5Fnaming-252F-26data-3D02-257C01-257Cgdr-2540microsoft.com-257C1139eb25a2ca43b5cb2e08d6770b6606-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636827288180838903-26sdata-3DtMhQa4ijeqUd2qxXV4loP47nU5NESRTKJLwZqe-252FI1fc-253D-26reserved-3D0&d=DwMGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=Yv6fjy4yWnfBkW_0m604prnwiQIO5K6DRLBHMjpiaxI&s=O9uUoT3QItO0vkb2QTG-EnXjsGfOiq7t93GgFz4YHx8&e=>
>
>
>
>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>