That looks good overall, except that it brings back the intentionally removed behavior of printing the built store paths thinking

@regnat There was still nobody whould could explain to me why $(nix build)/bin/whatever is an antipattern. The only "explanation" is the gc which is completely irrelevant in cases where I just want to execute a tool and I can just retry when it fails.
There is no alternative to this workflow (except this PR which requires me to ADDITIONALLY use jq (with its annoying syntax) instead of just $()

@regnat There was still nobody whould could explain to me why $(nix build)/bin/whatever is an antipattern. The only "explanation" is the gc which is completely irrelevant in cases where I just want to execute a tool and I can just retry when it fails.

I don't want to enter this debate. I didn't state any position, just noted that it might be controversial. But fwiw:

There is no alternative to this workflow (except this PR which requires me to ADDITIONALLY use jq (with its annoying syntax) instead of just $()

There are cases where it wouldn't work, but nix shell --run whatever actually does what you want (and is arguably nicer).

Thanks @regnat , applied those changes

@regnat I think including json_fwd requires passing PRECOMPILE_HEADERS=1 to make. Is that okay? And would that need to be added to the nix-shell instructions for make at https://nixos.org/manual/nix/unstable/hacking.html?

@regnat I think including json_fwd requires passing PRECOMPILE_HEADERS=1 to make. Is that okay? And would that need to be added to the nix-shell instructions for make at https://nixos.org/manual/nix/unstable/hacking.html?

No that shouldn't. I guess what's happening is that installables.cc was transitively including json.hpp via installables.hh.
So you need to explicitely include json.hpp in installables.cc.

The reason why it works with PRECOMPILE_HEADERS=1 is that this flag cause the compiler to first bundle all the external headers (including json and json_fwd) into one big precompiled thing precompiled-headers.h.gch which is systematically included. This is faster than all the individual includes because of the precompilation step, but the consequence is that when that flag is set all the external includes are redundant.

There are cases where it wouldn't work, but nix shell --run whatever actually does what you want (and is arguably nicer).

What are cases where you really do need nix build? To me it seems like even out links are pretty inconsistent with nix philosophy, since they can be left anywhere, rather than managed declaratively. nix shell --run whatever seems a lot nicer to me.

@mkenix Mainly for projects which are independent from nixpkgs. Not everything is fitted for nixpkgs, for example NixDroid.

Thanks!