On Fri, Jun 02, 2023 at 05:30:30 +0000, Olga Arkhipova via SG15 wrote:
> The paper proposes a call to an executable to produce a json format
> with the capabilities info. I am wondering if having a json file near
> the executable which would contain full info about what this tool
> supports would be more beneficial.

Note that there exist tools and systems which use "compiler wrappers" to
forward to the "real" compiler. These include:

  - MPI with its `mpicxx` wrapper
  - `ccache` and `sccache` caching layers
  - Spack injecting oodles of `-I` and `-Wl,-rpath` flags in for
    dependent packages

I'm sure there are more. Though in theory it is best to apply these to
the compiler manually, it is usually far easier to instead do
`CC=ccache` or have `/usr/lib64/ccache` in `$PATH` and use them
directly…especially with the variety of buildsystems one usually
encounters in the wild. Using just the compiler's path means that all of
these layers need to answer these queries as well via file paths.

> An external (but easy to find) file will allow getting the tool
> information even without launching its process, which would be
> preferred in perf sensitive scenarios. I also think that it would be
> easier for tool vendors to create (and maintain) this file rather than
> to implement the suggested functionality in code.

I think the assumption that it is always easy to know where the "real"
compiler lives is hard to answer (e.g., should one instead ask where
`cc1` is and search relative to that?)

> I think it should be at least included as a option.

An option, yes, but I suspect we'll end up with both in practice.

--Ben