Microsoft has some internal user experience as well. It is my (likely flawed) understanding that those internal users maintained dependency information by hand, rather than automatically generate it.

From: tooling-bounces_at_open-std.org <tooling-bounces_at_[hidden]> On Behalf Of Corentin
Sent: Thursday, January 10, 2019 1:52 PM
To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
Subject: Re: [Tooling] Modules naming

I suspect it will be a while (several years) before we start to see large projects transitioning fully to modules and consumed as such by tools doing automatic dependency scanning etc.
My understanding is that there is little large scale implementation experience as far as tooling and build systems are concerned ( there is plenty _compilers_ implementation experience, and some build system implementation (and usage of modules) experience - mostly in build2).



On Thu, 10 Jan 2019 at 18:47 JF Bastien <cxx_at_[hidden]<mailto:cxx_at_[hidden]>> wrote:
On Thu, Jan 10, 2019 at 6:53 AM Corentin <corentin.jabot_at_[hidden]<mailto:corentin.jabot_at_[hidden]>> wrote:
>
> 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.

Why does SG15 need to do this, versus someone implementing it in an
open-source toolchain, trying it out, and bringing what using it
taught them to SG15?


> 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__cor3ntin.github.io_posts_modules-5Fmapping_&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=wMVCtcOClnK6fSH49PWMZlyAyj-tqPvl6ev_V2t1am4&s=c6Usu_rfiWBfNCrWSIh0vPbUS5kf84PjTC5qGGkhZ1k&e=>
> https://cor3ntin.github.io/posts/modules_naming/<https://urldefense.proofpoint.com/v2/url?u=https-3A__cor3ntin.github.io_posts_modules-5Fnaming_&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=wMVCtcOClnK6fSH49PWMZlyAyj-tqPvl6ev_V2t1am4&s=CHSmj32vYThBch_8Q3k88FHC0qOTfhyYhfv-TlT_se0&e=>
>
>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]<mailto:Tooling_at_[hidden]>
> http://www.open-std.org/mailman/listinfo/tooling<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.open-2Dstd.org_mailman_listinfo_tooling&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=wMVCtcOClnK6fSH49PWMZlyAyj-tqPvl6ev_V2t1am4&s=BRyNt2DjC3eSa4B8CF5n67_k_0KPZUtumMt2FVQtE9Y&e=>
_______________________________________________
Tooling mailing list
Tooling_at_[hidden]<mailto:Tooling_at_[hidden]>
http://www.open-std.org/mailman/listinfo/tooling<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.open-2Dstd.org_mailman_listinfo_tooling&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=wMVCtcOClnK6fSH49PWMZlyAyj-tqPvl6ev_V2t1am4&s=BRyNt2DjC3eSa4B8CF5n67_k_0KPZUtumMt2FVQtE9Y&e=>