Date: Mon, 25 Feb 2019 00:39:16 -0500
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.
> 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
> 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.
> 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
Received on 2019-02-25 06:39:28