FromCabal.Name: more libNixName mappings

[sternenseemann]

No description provided.

[wolfgangwalther]

I'm not exactly sure how pkgs/top-level/pkg-config/pkg-config-data.json in nixpkgs is created, but I can't find any of these two in there. Do you know why?

[sternenseemann]

@wolfgangwalther manually. The data file is also duplicated with meta.pkgConfigModules. A while back, I started on a solution that would be able to (periodically) regenerate this data file from the meta sets elsewhere (since this is I think the best way to get ordinary maintainers involved in maintaining this list) with the plan to eventually integrate this into cabal2nix.

You can find it here: NixOS/nixpkgs#216488. If I remember correctly, it is basically finished, I just ran out of steam adding the missing meta.pkgConfigModules entries, so that no entry would be removed by the change. I also never got around to thinking about how to actually periodically, maybe even semi-automatically regenerating the file.

[roberth]

Not the most detailed mapping here, but lgtm.

[roberth]

Has libglog.so file, but no pkgconfig/*.pc

[roberth]

Has llama.so file and pkgconfig/llama.pc

[roberth]

Not the most detailed mapping here

Unclear whether that should be a goal, or some other solution is to be preferred.

[roberth]

I'm co-responsible for the defaultPkgConfigPackages mapping in Nixpkgs.
It'd be a good fallback, but I'm not sure that it's a complete solution.
Specifically some packages contain multiple pkg-config modules, and it'd be preferable to consume those through a single package function argument attribute, so that a single override changes the whole group of modules.
Otherwise, we risk that an incomplete override of some of the pkg-config modules causes for example an ABI compatibility problem.

[sternenseemann]

I guess you should not allow overriding modules, but instead resolved packages only (which is annoying in other situations though).

[roberth]

Something better could be created, but the interesting stuff won't happen within the broad callPackage area.
Probably the mapping in Nixpkgs needs to be more first-class instead of the already resolved attribute selections of defaultPkgConfigModules.
I'll "move" this to NixOS/nixpkgs#273815
Thanks for the merge!