On Tue, Mar 12, 2019 at 19:15:20 -0400, Ben Boeckel wrote:
> I've now implemented the format that was discussed the past two weeks in
> GCC and CMake (the implementation forgoes all `bikeshed-` prefixes). New
> Docker image is here:
>
> https://hub.docker.com/r/benboeckel/cxx-modules-sandbox (tag 20190312.1)
>
> Source code references are hosted here:
>
> https://gitlab.kitware.com/ben.boeckel/cxx-modules-sandbox/tree/docker-20190312.1

This has now been implemented for CMake's Fortran support as well:

    https://gitlab.kitware.com/ben.boeckel/cmake/tree/fortran-trtbd

This includes tests for corner-case path characters (using `%`, a
literal `%25`, valid UTF-8, UTF-8 encoded UTF-16 surrogate halves,
binary, Latin-1, and Shift-JIS paths) in the file format.

> What I'm looking for:
>
> - Are there any properties which should be added? Note that none seem
> necessary given the working implementation I have.

There was discussion here and on Slack about extension properties. Two
concerns were de facto standards being made with extension keys, where
to place additional information that can be useful to a build system,
and attributes on import/export statements. Here are my thoughts on the
three issues:

# De facto standard fields.

These can become an issue if they start to crop up. In order to avoid
this problem, I propose that all fields provided that not specified in
the specified version / revision are hard errors. This avoids issues
where compilers start saying "hey, this is useful", one build tool gains
support, and then users start asking why other build tools don't do
something properly. We have a hard enough problem on our hands; let's
not make it more complicated right away.

# Build system information.

Build systems may want information like "what's the cost of importing
this module" to better schedule compilations. Other information may be
useful in the future as well.

For this, a field named `extensions` to the objects in the `sources`
array. It is specified only in that it is a valid JSON object and that
implementations that *completely ignore* the field MUST still be able to
create correct builds. Information which ends up being required for a
proper build should seek to be specified in a future version or revision
of the format specification.

Given a trtbd file, the following being performed MUST NOT change the
validity of the build from either the build tool or compiler's
viewpoint:

    jq 'del(.sources[].extensions)' < old.trtbd > new.trtbd

# Attributes on export/import.

The example given was:

    import foo [[version: 1]];

Adding the information is fine, but that leaves interpretation up to
being specified. I think that for version 1, attributes are expressly
ignored for now until we have actual semantics for what each attribute
means and how build tools should use it to "match" import and export
statements. Once we have more experience with modules, we can start to
say "hey, these attributes are useful and here is what they mean".

Thanks,

--Ben