<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 &lt;<a href="mailto:mwoehlke.floss@gmail.com">mwoehlke.floss@gmail.com</a>&gt; 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>
&gt; I think the information _should_ be in the source file.<br>
&gt; The goal should be to simplify the use of tools as much as we want to<br>
&gt; simplify (or make possible) their implementation.<br>
<br>
I don&#39;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&#39;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">
&gt; Asking people to manually maintain a module mapping for every project<br>
&gt; doesn&#39;t seem to be a reasonable stance given:<br>
&gt; <br>
&gt;    - The information would have to be encoded in the build system too<br>
&gt;    anyway because build systems will have different requirements than these<br>
&gt;    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>
&gt;    - Each dependency would have to have a similar file which both compilers<br>
&gt;    and tools would have to search for<br>
<br>
Yes, but so what? This is already true of includes. I don&#39;t see how this<br>
would be any worse.<br>
<br>
What&#39;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&#39;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>
&gt; Any project beyond a simple Hello World has some of its state in a build<br>
&gt; system, and the only accurate way to build or parse a TU is to ask the<br>
&gt; 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&#39;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&#39;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">
&gt; It would be nice that the source code was the single source of truth. The<br>
&gt; preprocessor has been prohibiting that since forever (and it is not<br>
&gt; something we can fix any time soon).<br>
&gt; It would, therefore, be preferable not to introduce a third source of truth<br>
&gt; beyond the build system and the files.<br>
<br>
I understand the desire, but let&#39;s also understand the costs...<br></blockquote><div><br></div><div>Let&#39;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>
&gt; In such a scenario, the file would be updated by invoking the build system<br>
&gt; (which would *NOT* need to compile anything) to update the file, but a scan<br>
&gt; 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&#39;s fair.</div><div>I don&#39;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>