Adding a C++ dependency to a package in Nix haskellPackages

Learn
#1

I maintain a Haskell package called opencascade-hs, this is an ffi wrapper for the C++ library opencascade. It’s a “CAD kernel”, a library that can be used to design solid objects.

Opencascade is packaged for Nix, under opencascade-occt.
However, the Nix haskellPackages export of opencascade-hs does not pick up on this dependency, so it’s currently marked as broken.

I’ve made an example project building a program that uses opencascade-hs, under Nix, using package overrides here.

I’d like to add the dependency to the version of opencascade-hs that appears in Nix under haskellPackages, so that people can “just use it” but it’s not clear to me how I would go about doing this?

(As a heads up, I’m completely new to using Nix, so it’s possible I’m doing something stupid here)

#2

I think you can add your change somewhere here:

You should probably use the “appendConfigureFlags” helper :slight_smile:

1 Like
#3

Actually I don’t think you need to mess with configure flags, since they are added automatically if some other stuff is set up correctly. You can find lots of examples of Haskell packages that depend on non-Haskell packages in Nixpkgs that don’t mess with overriding configure flags.

First, it looks like your Haskell package picks up the opencascade C lib by including /usr/include/opencascade under the include-dirs stanza (source). That’s fragile and certainly won’t work with Nix. :slight_smile:

Beyond that, adding the right tweaks to your cabal file is all that should be needed. Somebody more knowledgeable than me will need to tell you what tweaks, exactly.

Finally, I can’t find it now, but somewhere in Nixpkgs [edit: it’s in the source code of cabal2nix] is a mapping from common package names to their name in Nixpkgs. So if the problem ends up being that your package is looking for opencascade, but Nixpkgs provides opencascade-occt, that would need to be fixed outside of your cabal file.

2 Likes
#4

I agree that this isn’t ideal, but it’s not clear to me how to link to the opencascade headers without doing that. The headers themselves assume that the opencascade directory is on the include path, so you can’t #include them with the relative path from /usr/include.

Finally, I can’t find it now, but somewhere in Nixpkgs [edit: it’s in the source code of cabal2nix] is a mapping from common package names to their name in Nixpkgs. So if the problem ends up being that your package is looking for opencascade, but Nixpkgs provides opencascade-occt, that would need to be fixed outside of your cabal file.

Are you suggesting I should PR cabal2nix to add opencascade to that mapping of package names? That’s certainly something I’d be happy to do

#5

No, not yet. You might just need to make tweaks to the cabal file. Let’s wait and see if somebody else knows what needs doing.

1 Like
#6

It’s possibly worth highlighting that there isn’t one opencascade shared library: the opencascade libraries (as configured in extra-libraries) are granular, and have names like TKGeomBase

#7

I’ve got a couple of potential fixes for this:

PRing cabal2nix to add support for the opencascade-libraries

The PR’s over here, I still need to track down a cabal2nix maintainer to take a look at it.

I’m relatively confident in the idea of adding the opencascade libraries to the libNixName function, although there are a lot (67) of them.

I’m less confident that this is the right place for the hook setting the --extra-include-dir flag, although as mentioned above, this does need to be set somewhere.

Updating configuration-common in nixpackages

A friend of mine came up with this patch to nix packages, which also works to fix the build.

This flake references that branch, and demonstrates that this fixes the build.

It’s not particularly clear to me which of these two solutions is best?

I think there might be a case for updating libNixName, but keeping the extra-include-dir in configuration-common.
libNixName is a mapping from library name to nix package, and making this more complete would seem to be a good thing, whereas by comparison, the --extra-include-dir flag is a hack to work around the limitations in the way the underlying opencascade library have set up their imports.
On the down side, this involves making changes in two separate places.