Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get pkg-config dependencies from pkg-configPackages #594

Open
2 tasks
roberth opened this issue Jan 25, 2023 · 5 comments
Open
2 tasks

Get pkg-config dependencies from pkg-configPackages #594

roberth opened this issue Jan 25, 2023 · 5 comments

Comments

@roberth
Copy link
Member

roberth commented Jan 25, 2023

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

@sternenseemann
Copy link
Member

sternenseemann commented Jan 25, 2023

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
Copy link
Member Author

roberth commented Jan 25, 2023

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

@sternenseemann
Copy link
Member

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
Copy link
Member Author

roberth commented Jan 25, 2023

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants