<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 8 Feb 2019 at 20:07 Matthew Woehlke <<a href="mailto:mwoehlke.floss@gmail.com">mwoehlke.floss@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 08/02/2019 12.59, Corentin wrote:<br>
> I think the information _should_ be in the source file.<br>
> The goal should be to simplify the use of tools as much as we want to<br>
> simplify (or make possible) their implementation.<br>
<br>
I don't see how this improves things for tools. AFAICT it has the<br>
*opposite* effect.<br></blockquote><div><br></div><div>Yes, but the added complexity should fall on tool authors, not users.</div><div>I know, easy to say, hard to do.</div><div>But let's not ask people to do more build system maintenance, which is costly</div><div>in term of resources and time. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Asking people to manually maintain a module mapping for every project<br>
> doesn't seem to be a reasonable stance given:<br>
> <br>
> - The information would have to be encoded in the build system too<br>
> anyway because build systems will have different requirements than these<br>
> files<br>
<br>
...Are you sure? Example, please.<br></blockquote><div><br></div><div>Files conditionally included according to some macros, platforms, the presence of a library, etc.</div><div>And generated files and so forth.</div><div><br></div><div>So either the information has to be duplicated ( to the extent that it can),</div><div>or the manifest file is as complicated as any build script, neither of which is desirable</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> - Each dependency would have to have a similar file which both compilers<br>
> and tools would have to search for<br>
<br>
Yes, but so what? This is already true of includes. I don't see how this<br>
would be any worse.<br>
<br>
What's a problem is scattering the information about what modules come<br>
from where all throughout the project. In this model, we have to scan a<br>
ton of files and collate the results before we can even guess at<br>
dependencies, which adds complexity and creates bottlenecks.<br></blockquote><div><br></div><div>Hopefully, when you attempt to build anything, the set of files is finite an known.</div><div>Which isn't to say that it is easy to collect but the information is where it needs to be.</div><div>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</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Any project beyond a simple Hello World has some of its state in a build<br>
> system, and the only accurate way to build or parse a TU is to ask the<br>
> build system for the relevant info.<br>
<br>
Sure, but with the current model there is NO case where this can be even<br>
partially done without partially building the project first.<br></blockquote><div><br></div><div>You only need to scan the project, not to build it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With a module map, you might still have generated files (*including* the<br>
module map itself), but at least it's plausible to try to parse the<br>
project after the build files have been generated but before it has been<br>
built.<br></blockquote><div><br></div><div>That's true if the scanning only happens as part of the build</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> It would be nice that the source code was the single source of truth. The<br>
> preprocessor has been prohibiting that since forever (and it is not<br>
> something we can fix any time soon).<br>
> It would, therefore, be preferable not to introduce a third source of truth<br>
> beyond the build system and the files.<br>
<br>
I understand the desire, but let's also understand the costs...<br></blockquote><div><br></div><div>Let's consider the cost of putting even more strain on developers.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> In such a scenario, the file would be updated by invoking the build system<br>
> (which would *NOT* need to compile anything) to update the file, but a scan<br>
> of modified files as well as potentially a configuration step<br>
<br>
This is not true in the case of generated source files. Aside from<br>
absolutely precluding that the file can be generated at configure time<br>
(note: it is more likely that a generated *module map* can be generated<br>
at configure time), it may well be that in order to generate the source<br>
files to generate the module dependencies, we must first compile the<br>
executable that will generate those files.<br></blockquote><div><br></div><div>Sure, that's fair.</div><div>I don't think it is an issue</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- <br>
Matthew<br>
_______________________________________________<br>
Tooling mailing list<br>
<a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
</blockquote></div></div>