On Fri, 8 Feb 2019 at 20:07 Matthew Woehlke <mwoehlke.floss_at_[hidden]>
wrote:

> 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.
>

Yes, but the added complexity should fall on tool authors, not users.
I know, easy to say, hard to do.
But let's not ask people to do more build system maintenance, which is
costly
in term of resources and time.


> > 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.
>

Files conditionally included according to some macros, platforms, the
presence of a library, etc.
And generated files and so forth.

So either the information has to be duplicated ( to the extent that it can),
or the manifest file is as complicated as any build script, neither of
which is desirable


> > - 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.
>

Hopefully, when you attempt to build anything, the set of files is finite
an known.
Which isn't to say that it is easy to collect but the information is where
it needs to be.
I do think that having the name if the module in the name of the file of
interface header units would make scanning easier, especially for non-build
system tools and tools such as make


>
> > 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.
>

You only need to scan the project, not to build it.

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.
>

That's true if the scanning only happens as part of the build


> > 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...
>

Let's consider the cost of putting even more strain on developers.


>
> > 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.
>

Sure, that's fair.
I don't think it is an issue


>
> --
> Matthew
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>