<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 25, 2019 at 6:39 AM Ben Boeckel &lt;<a href="mailto:ben.boeckel@kitware.com">ben.boeckel@kitware.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Feb 23, 2019 at 22:36:28 -1000, Mathias Stearn wrote:<br>
&gt; I actually think that we should use this opportunity to switch to a<br>
&gt; standardized data format, such as JSON, that has parsers for basically<br>
&gt; every language (even make could use something like jq) for exchanging<br>
&gt; metadata between the compiler, build systems and other tools.<br>
<br>
I have GCC writing out JSON-like syntax right now. It isn&#39;t 100% valid<br>
since it isn&#39;t UTF-8, but I don&#39;t want *that* in these files either.<br>
Note that right now, extra information is still necessary for<br>
communicating with the build tool since the compiler is unaware of the<br>
build&#39;s root directory, so paths may need prefixed before handing off to<br>
the build tool for accuracy.<br></blockquote><div><br></div><div>In the compilation database (<a href="https://clang.llvm.org/docs/JSONCompilationDatabase.html">https://clang.llvm.org/docs/JSONCompilationDatabase.html</a>) we specify the build dir for each file.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; I really don&#39;t want to have to teach every tool to read Makefile syntax. It<br>
&gt; is also extremely limited in what it can tell you, and we may need/want a<br>
&gt; lot more kinds of data that it can provide.  Eg the hash that should be<br>
&gt; used to  detect thst the interface has changed in a way that doesn&#39;t need a<br>
&gt; rebuild of importers, or the list of bmi-altering flags in from the current<br>
&gt; command.<br>
<br>
Agreed. Especially with the ambiguities that GCC outputs with fun like:<br>
<br>
    #include &quot;path with spaces.h&quot;<br>
    #include &lt;path\with\slash.h&gt;<br>
    #include &lt;path\ending\in\\&gt; // Need two to avoid confusing the escape, but the depfile is not good.<br>
<br>
&gt; lot more kinds of data that it can provide.  Eg the hash that should be<br>
&gt; used to  detect thst the interface has changed in a way that doesn&#39;t need a<br>
&gt; rebuild of importers, or the list of bmi-altering flags in from the current<br>
&gt; command.<br>
<br>
Well, you can&#39;t know until you actually compile the BMI whether it has<br>
changed or not. The best we can ask for is &quot;only update if contents are<br>
unchanged&quot;. Getting that for .o files would be nice as well. Ninja can<br>
then optimize no-change compilations via `restat`.<br>
<br>
&gt; And for the love of $diety, don&#39;t put any locale- sensitive strings in this<br>
&gt; metadata!<br>
<br>
I&#39;d rather have it just be &quot;a series of bytes that is a valid lookup on<br>
the filesystem&quot;. The `\` and `&quot;` characters are escaped using `\` for<br>
obvious reasons. Maybe we do it for control characters as well. Is that<br>
good enough for a specification?<br>
<br>
--Ben<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></div>