NixOS / cabal2nix

Generate Nix build instructions from a Cabal file
https://haskell4nix.readthedocs.io
Other
355 stars 154 forks source link

Get pkg-config dependencies from `pkg-configPackages` #594

Open roberth opened 1 year ago

roberth commented 1 year ago

I wrote https://github.com/NixOS/nixpkgs/pull/212282 as a proposal to centralize this mapping in Nixpkgs. Do you think it is fit for the purpose of cabal2nix?

sternenseemann commented 1 year ago

In principle there is no reason why we can't use that for special pkg-config specific code in distribution-nixpkgs. This does, however, not mean that we can drop the libNixName code, since we also need to deal with the extra-libraries field and friends where lib$NAME is specified as would be passed to the linker via -l.

It is nice to have some of the ongoing maintenance in nixpkgs in any case, but I'm not sure if it makes stuff simpler in cabal2nix (but maybe that's just life).

roberth commented 1 year ago

I suppose a similar libPackages may be a welcome addition then? It could follow the same pattern.

sternenseemann commented 1 year ago

I suppose a similar libPackages may be a welcome addition then? It could follow the same pattern.

Have my reservation about this idea, but I think it's a question we can revisit later.

roberth commented 1 year ago

It does complicate the interface for overriding. Maybe it'd be better to consume a json, so that the overriding interface remains unchanged. That'd make the function parameters dynamic though, so it will look a bit messier in the generated code, with some setFunctionArgs wrappers that depend on the outcome of some lookups. Perhaps this idea is more appropriate for a far future iteration of Nixpkgs that uses module-style fixpoints instead of functions to define packages. I think that might be a better fit, but I'll stop speculating now.

sternenseemann commented 1 year ago

Passing in a JSON lookup table was going to be my answer anyways for RFC 109. The lookup table would be used at generation time though, no need to generate eval time lookups when we can already lookup at generation time.