On Wed, Mar 06, 2019 at 07:29:54 -0500, Nathan Sidwell wrote:
> Have I mentioned nearly all the gcc-module additions have been rewritten
> 4 times? No matter how polished you make it, it'll change!

Well, the depformat stuff is probably distinct enough at the moment.
But yes, I'm aware of the current state :) .

> On 3/5/19 9:56 AM, Ben Boeckel via Modules wrote:
> > There may be other output files (.pdb, .dwo, etc.) that are never
> > mirrored in a "requires" field, so I think they should stay separate.
>
> I'm confused. Why cannot such other outputs be listed in a provides?
>
> "provides": [ {"object":"source.o" {"module": "I"} {"bmi": "I.gcm"}
> {"pdb": "source.pdb"} ]

I don't care *why* things are output and having to divine the meaning of
keys like "object" and "pdb" is, to me, noise from a build system
point-of-view. The build system just care about what they are. As for
the separate `module` and `bmi`, there needs to be a stronger link to
know that `I`'s BMI is called `I.gcm`. Fortran would otherwise have it
as something like:

    "modules": ["math", "util"],
    "bmis": ["util.mod", "math.mod"]

and I don't want to have heuristics to guess which goes with which
(consider BMI file names being generated from content hashes or the
like).

> It seems a useful classification to group outputs (and inputs). I don't
> see why there has to be a link to a requires field. (you need this
> compilation because you find it provides module X, which you require
> somewhere else, but hey, you also get this lovely pdb file!)

Yes, that's why `outputs` is an array :) . The difference is that those
are useful in a *different* step (linking) that already has to wait for
compilations to be complete. The `provides` and `requires` is for
compilation step ordering details which is why they are specified
separately.

> > We can bikeshed names, but how about `module-imports` and
> > `compile-depends` instead for now?
>
> I continue to think that 'depends' is a really poor choice of name.

That's fine, names can be bikeshedded later (should have been more
clear). But the separation between the keys I proposed is still
important. I'll have a new reply to the top-level describing updates
considering the discussion that has occurred. It will also have better
prose about what each key actually means and why they're separate
(rather than the short blurbs that happen to fit alongside the example).

> > Also, this should not be C++ specific…I think the same overall format
> > can be used for Fortran as well.
>
> Excellent point. What does fortran need?

Fortran can output more than one module from a single TU. This is the
reason `logical-provides` is a mapping, not a single string (like I had
in a previous version of the GCC patch).

Thanks,

--Ben