>
>
> > 4. No drastically different file formats to parse (like binary module
> > interfaces).
>
> Exposed to the build system at least. I imagine there will be internal
> formats for persisting this information on disk. I think the best that
> can be asked for is documentation, but I don't know that is something
> that build systems can require (tools doing static analysis may need to
> know however).
> Module maps are a thing in GCC and Clang, so they have it. Bikeshedding
> on the format of it so that it can be shared among implementations would
> be a nice-to-have in the TR.
>


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 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.

And for the love of $diety, don't put any locale- sensitive strings in this
metadata!

>