FFI issue: missing flake/flake.hh in API exposed in include/nix

[yannham]

Hello,

I didn't really know how to categorize the issue. Nickel links against the Nix C++ API in order to run basic Nix expression from Nickel programs, whenever the feature is enabled. However, with the update to latest unstable Nixpkgs, featuring nix-2.24.0pre20240629_32e6cc6-dev, this doesn't build anymore.

Here is the g++ error:

cargo:warning=In file included from /nix/store/zx459iv75gnkrzmjha0bgzbdgxcn1p7c-nix-2.24.0pre20240629_32e6cc6-dev/include/nix/command.hh:4,
  cargo:warning=                 from src/nix_ffi/cpp/nix.cc:12:
  cargo:warning=/nix/store/zx459iv75gnkrzmjha0bgzbdgxcn1p7c-nix-2.24.0pre20240629_32e6cc6-dev/include/nix/installable-value.hh:5:10: fatal error: flake/flake.hh: No such file or directory
  cargo:warning=    5 | #include "flake/flake.hh"
  cargo:warning=      |          ^~~~~~~~~~~~~~~~
  cargo:warning=compilation terminated.

Indeed, after verification, in the /nix/store/zx459iv75gnkrzmjha0bgzbdgxcn1p7c-nix-2.24.0pre20240629_32e6cc6-dev/include/nix directory, it seems that flake/flake.hh is referenced from installable-value.hh but there is no flake directory here. Going back randomly to a previous version (say 2.19) in the store, the flake/flake.hh file is indeed there in the include directory.

[roberth]

Flake logic has been modularized into its own library, so you'll have to link libnixflake as well as libnixexpr.

We don't intende to support the C++ interfaces as a stable public API, but we are working on a stable C API you could use instead. It's probably not suited yet, but explicit flake support is planned:

• C API: Flakes, locking, override-input #10435

[yannham]

Thank you for the quick reply.

I think what confused me is that the bits around expression evaluation (so libnixexpr) and all others seem to still be there (such as nixexpr), but not the flake.hh header, so I wondered if this was an oversight of some sort.

Yeah, I'm very much looking forward to the stable C API - this is a great initiative. In the meantime linking against the C++ API hasn't been that bad (when using only high-level functionalities like evaluate this expression).

I'm going to try adding the right options to find this header and will close here if it's solved.

[Ericson2314]

I think we probably just needed to move some wildcard header logic I forgot to move.