On 08/02/2019 12.59, Corentin wrote:
> I think the information _should_ be in the source file.
> The goal should be to simplify the use of tools as much as we want to
> simplify (or make possible) their implementation.

I don't see how this improves things for tools. AFAICT it has the
*opposite* effect.

> Asking people to manually maintain a module mapping for every project
> doesn't seem to be a reasonable stance given:
>
> - The information would have to be encoded in the build system too
> anyway because build systems will have different requirements than these
> files

...Are you sure? Example, please.

> - Each dependency would have to have a similar file which both compilers
> and tools would have to search for

Yes, but so what? This is already true of includes. I don't see how this
would be any worse.

What's a problem is scattering the information about what modules come
from where all throughout the project. In this model, we have to scan a
ton of files and collate the results before we can even guess at
dependencies, which adds complexity and creates bottlenecks.

> Any project beyond a simple Hello World has some of its state in a build
> system, and the only accurate way to build or parse a TU is to ask the
> build system for the relevant info.

Sure, but with the current model there is NO case where this can be even
partially done without partially building the project first.

With a module map, you might still have generated files (*including* the
module map itself), but at least it's plausible to try to parse the
project after the build files have been generated but before it has been
built.

> It would be nice that the source code was the single source of truth. The
> preprocessor has been prohibiting that since forever (and it is not
> something we can fix any time soon).
> It would, therefore, be preferable not to introduce a third source of truth
> beyond the build system and the files.

I understand the desire, but let's also understand the costs...

> In such a scenario, the file would be updated by invoking the build system
> (which would *NOT* need to compile anything) to update the file, but a scan
> of modified files as well as potentially a configuration step

This is not true in the case of generated source files. Aside from
absolutely precluding that the file can be generated at configure time
(note: it is more likely that a generated *module map* can be generated
at configure time), it may well be that in order to generate the source
files to generate the module dependencies, we must first compile the
executable that will generate those files.

-- 
Matthew