Config.summary file: copy to $out?

Development
1

in some packages, the configurePhase generates a config.summary file
with a list of enabled features and disabled features

to me, it seems useful to store that file somewhere in $out
as a human-readable way of feature-detection
(“does derivation X have feature Y?”)
(“is feature X disabled or broken?”)

example:

{
  postInstall = ''
    # save Configure summary
    mkdir $out/share || true
    cp -v config.summary $out/share/
  '';

good idea? bad idea?

what would be a good default location?

$out/share/config.summary
$out/share/doc/config.summary
$out/etc/config.summary
$out/var/config.summary
$out/doc/config.summary
…

2

If people just want to “inspect” the file, it might be worthwhile to split it out to it’s own output. If the file is expected to be used only at build time, then put it in the dev output, if it’s normally inspected as part of downstream usage, then out makes sense.

For the directory path after the output, I don’t have a good answer.

3

Wouldn’t nix-support be a good place for it?

4

nix-support is usually so that some runtime dependency doesn’t get dropped because nix isn’t able to find the related store path (e.g. library paths in a jar file, which is compressed)

For the path, I meant share vs etc. I would assume that upstream has some convention already.

5

@jonringer @nrdxp Not exactly the same purpose, but I’ve wondered what (if any) interesting tools people could build on top of a good foundation of build-time metadata published alongside packages (in, or separate output). Ideally normalized across toolchains.

I know resholve has some potential uses (around better-identifying executables that will try to exec their own arguments), but I’m less sure if it’s just a distinct case, or if there are many other levers to build. I suspect some of them could at least be useful for building some nixpkgs-oriented auditing/maintenance tools?

A lot of what I have in mind is source-analysis-y stuff. Call graphs. Lists of: direct syscalls used, files read/written, environment variables read/written, executables that read argv, hardcoded path-like strings, CLI help/usage strings…