Hi,

After today's tcon and discussion with Brad here, a few changes and
clarifications:

On Tue, Mar 12, 2019 at 19:15:20 -0400, Ben Boeckel wrote:
> "future-depinfo": {
> "$id": "#future-depinfo",
> "type": "object",
> "bikeshed-outputs": {
> "$id": "#outputs",
> "type": "array",
> "description": "Files output by a future rule for this source using the same flags",

Clarification: these are the files that the scan step *knows* will be
output. If the path is configuration at some future point (e.g., GCC's
module maps), it is *not* included here.

> "module-desc": {
> "$id": "#module-desc",
> "type": "object",
> "required": [
> "bikeshed-logical"
> ],
> "properties": {
> "bikeshed-filepath": {
> "$ref": "#/definitions/filepath"
> },

Prose change: This should only be included if the compiler is inflexible
with the filepath that will be output by the compiler. For example,
Fortran compilers do not, historically, support custom module output
file names or directories. For GCC and C++, it would just never be
specified is configurable via the module map mechanism.

In response to worries about performance of the format, information may
be excluded from the output (e.g., not specifying any `depends` paths).
However, it should be noted that this may cause an incorrect build since
the information is incomplete. I expect build tools will assume that
such information is accurate and complete, but they can't really assume
anything else anyways. This should allow for flags equivalent to
`-fdep-scan-fast` for the cited IntelliSense use case. Tools like CMake
or ninja would just never want to use that flag.

Thanks,

--Ben