[SAHChandler]

(Hi, author of the article)

The issue is, "how do you find these dependent modules?". As of right now, there is no way to find a module. It is not tied to a location in a subdirectory, nor is the name of a module tied to the file itself. I'm fine if we can get the dependency information, but how can we do that if there is no guarantee for finding the actual dependencies? Leaving these decisions unspecified by the C++ standard is dangerous. Having an important thing such as "how does the name of a module map to the name of the translation unit it contains?" be none of "undefined", "ill-formed", or "implementation defined" is asking for trouble. And to be quite honest, I don't see how running the compiler in a minimal parsing mode (once for each module), followed by running the compiler a second time for its full IFC (or whatever file format is used) and possible object file generation can be a good idea.

[gpderetta]

Running the compiler twice (first in preprocessor mode), then in actual compilation mode is exactly what is done now for many build systems. The first pass, in addition to building dependencies also generates the mapping from files to modules. You will need to list all the files you need to 'preprocess' in your build script, to generate the dependencies, but that's what it is done today already and I don't see a way out nor even a need to change. Modules are not supposed to enforce a specific build strategy, nor they should.

The standard currently imposes very little requirements on the actual build process, headers and source files do not even need to exist as actual files on a system, so it would be a lot of work to actually introduce these concepts in the standard and risk delaying modules further.

That doesn't mean that there might not valuable to standardize that, but it is another battle and many (I, for example) will argue that a strict mapping from file names to module names is wrong.

[SAHChandler]

Forgive me, but I can't think of a single build system where the compiler is run on a source file twice. All of the ones I've seen support either parsing the .d file generated by a compiler, or parse /showIncludes if using MSVC. If you have any examples of build systems doing this, I'd love to see them so I can avoid them.

[dcohenp]

I've seen at least one, but it's proprietary and internal to my bigco. I'm willing to bet there's quite a few more at other bigcos. So lucky for you if you can avoid them, but I'm pretty sure there's many of us who don't get that choice.