On Fri, Jun 18, 2021 at 12:21 PM Daniel Ruoso <daniel_at_[hidden]> wrote:

> On Fri, Jun 18, 2021 at 3:17 PM David Blaikie <dblaikie_at_[hidden]> wrote:
>
>> Makes sense. Is there one of the existing formats (sounds like
>> pkg-config) that seems like a fairly good candidate for
>> generalization/being championed in this effort, or is it likely that a new
>> format would be created here?
>>
>
> pkg-config is definitely a very viable candidate, but it would move things
> a bit beyond the scope of modules and jump into "package management" in
> general, which could be a political trap. Making a modules-specific
> solution could be fairly straight-forward, and be completely orthogonal to
> pkg-config, so that may be more attractive from a pragmatic perspective.
>
> But I want to avoid jumping into the solution before we have consensus on
> the requirements.
>

Fair enough - my take on that would be...

All this is not strictly necessary, but I think good/nice to have and an
appropriate fit for the ecosystem as I understand it. (alternatives include
libcody/module mapper https://github.com/urnathan/libcody etc - but I think
it's reasonable that some build systems may not be able to cope with this
sort of callback based system and instead need to know the module
dependence graph up-front. There's also the clang-scan-deps approach (works
for Clang Header Modules because it can still use the header search path -
but probably needs /some/ of the features described in your (Daniel)
proposal for C++ modules), though that doesn't surface the ability to
customize compilation flags for external modules)

R1, R2: Yep, sounds good.
R3: Less in agreement. I wouldn't object to that being optionally supported
for potential performance improvements (though would be good to have data
suggesting that that matters - and if it's optionally supported we could
always wait until broader adoption before adding it & those who want the
extra performance could add it in (but whether they could convince their
external library producers to add it in would then be more challenging)) -
but that doesn't reduce the complexity of consumers since they couldn't
rely on it being present.
R4, R5 (& I guess R6): I think these are probably "quality of
implementation" things (in that a vendor could readily say "I'm not the
same 'platform' as those other compilers, even though I'm on the same OS,
etc") - whether two vendors want to cooperate on making their configs
interoperable is probably going to be up to them & yeah, GCC and Clang (&
any other GCC-like compilers) would likely continue to do that in the same
way as has been done before.

- Dave