On Mon, Feb 25, 2019 at 6:39 AM Ben Boeckel <ben.boeckel_at_[hidden]> wrote:

> On Sat, Feb 23, 2019 at 22:36:28 -1000, Mathias Stearn wrote:
> > I actually think that we should use this opportunity to switch to a
> > standardized data format, such as JSON, that has parsers for basically
> > every language (even make could use something like jq) for exchanging
> > metadata between the compiler, build systems and other tools.
>
> I have GCC writing out JSON-like syntax right now. It isn't 100% valid
> since it isn't UTF-8, but I don't want *that* in these files either.
> Note that right now, extra information is still necessary for
> communicating with the build tool since the compiler is unaware of the
> build's root directory, so paths may need prefixed before handing off to
> the build tool for accuracy.
>

In the compilation database (
https://clang.llvm.org/docs/JSONCompilationDatabase.html) we specify the
build dir for each file.


> > I really don't want to have to teach every tool to read Makefile syntax.
> It
> > is also extremely limited in what it can tell you, and we may need/want a
> > lot more kinds of data that it can provide. Eg the hash that should be
> > used to detect thst the interface has changed in a way that doesn't
> need a
> > rebuild of importers, or the list of bmi-altering flags in from the
> current
> > command.
>
> Agreed. Especially with the ambiguities that GCC outputs with fun like:
>
> #include "path with spaces.h"
> #include <path\with\slash.h>
> #include <path\ending\in\\> // Need two to avoid confusing the escape,
> but the depfile is not good.
>
> > lot more kinds of data that it can provide. Eg the hash that should be
> > used to detect thst the interface has changed in a way that doesn't
> need a
> > rebuild of importers, or the list of bmi-altering flags in from the
> current
> > command.
>
> Well, you can't know until you actually compile the BMI whether it has
> changed or not. The best we can ask for is "only update if contents are
> unchanged". Getting that for .o files would be nice as well. Ninja can
> then optimize no-change compilations via `restat`.
>
> > And for the love of $diety, don't put any locale- sensitive strings in
> this
> > metadata!
>
> I'd rather have it just be "a series of bytes that is a valid lookup on
> the filesystem". The `\` and `"` characters are escaped using `\` for
> obvious reasons. Maybe we do it for control characters as well. Is that
> good enough for a specification?
>
> --Ben
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>