<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 <<a href="mailto:ben.boeckel@kitware.com">ben.boeckel@kitware.com</a>> 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>
> I actually think that we should use this opportunity to switch to a<br>
> standardized data format, such as JSON, that has parsers for basically<br>
> every language (even make could use something like jq) for exchanging<br>
> metadata between the compiler, build systems and other tools.<br>
<br>
I have GCC writing out JSON-like syntax right now. It isn't 100% valid<br>
since it isn't UTF-8, but I don'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'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">
> I really don't want to have to teach every tool to read Makefile syntax. It<br>
> is also extremely limited in what it can tell you, and we may need/want a<br>
> lot more kinds of data that it can provide. Eg the hash that should be<br>
> used to detect thst the interface has changed in a way that doesn't need a<br>
> rebuild of importers, or the list of bmi-altering flags in from the current<br>
> command.<br>
<br>
Agreed. Especially with the ambiguities that GCC outputs with fun like:<br>
<br>
#include "path with spaces.h"<br>
#include <path\with\slash.h><br>
#include <path\ending\in\\> // Need two to avoid confusing the escape, but the depfile is not good.<br>
<br>
> lot more kinds of data that it can provide. Eg the hash that should be<br>
> used to detect thst the interface has changed in a way that doesn't need a<br>
> rebuild of importers, or the list of bmi-altering flags in from the current<br>
> command.<br>
<br>
Well, you can't know until you actually compile the BMI whether it has<br>
changed or not. The best we can ask for is "only update if contents are<br>
unchanged". Getting that for .o files would be nice as well. Ninja can<br>
then optimize no-change compilations via `restat`.<br>
<br>
> And for the love of $diety, don't put any locale- sensitive strings in this<br>
> metadata!<br>
<br>
I'd rather have it just be "a series of bytes that is a valid lookup on<br>
the filesystem". The `\` and `"` 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>