On Tue, Mar 05, 2019 at 03:52:43 +0100, Corentin wrote:
> Quick suggestions:
>
> outputs = > doesn't seem useful to me ?

Useful to know when flags will cause additional files to be output
(e.g., -gsplit-dwarf will cause a .dwo file in addition to a .o file)

> logical-provides => exported-modules ( there can not be more than 1)

In C++. Fortran (which this should also support) can have multiple.
Sorry, should have mentioned that in a footnote.

> requires => required-modules

Or imported-modules. I'm not too concerned with the name right now.

> Version => only one field should be enough (with a separator)

Eh, I didn't want to use a float and a string implies that things like
`.someext` could be added.

> As for utf8 I would maybe not care about it? It would make the file json-like
> rather than json, but it might be better to system-encode it? It's not
> meant to be shared

No, JSON parsers reject non-Unicode commonly. My initial message about
it (in Ben Craig's first thread after Kona) discussed not doing
system-encoding since that isn't JSON.

> And pretending filename are Unicode consistently leads to pain,
> unfortunately.
> I think the TR should address these issues at some point :)

That's why there are the `raw8` and such format object bits exist.

> Do we want to add a field for partitions specifically?

IMO, this is supported here:

    "logical-provides": {
        "M:part1": "M.part.gcm"
    },
    "provides": {
        "M:part1"
    }

> I would support multiple files, ie
>
> {
> files : [
> "foo.cpp": {
> "requires" : ...
> }
> ]
> }

A scan step which handles multiple files can write out multiples of
these files. Is there any reason that is not sufficient?

> I would add a field (globally for the file), that gives the basepath for
> relative paths
> By default, I would make relatives paths relatives to the JSON file?

They should be relative to the working dir of the compiler. -MF output
path could be /dev/stdout which has no real "path" to be relative to.

> Maybe add a global list of include paths since build systems often have to
> extract that from the compiler?

Why? CMake does that at configure time (and then passes it as -I flags
later, so it already knows this). Where would this information be used?

--Ben