Do install and copy do the exact same thing here? Is there no difference in the output derivation?

Would you be able to provide some proof that this doesn't actually break anything?

I'm imagining taking a bunch of popular Haskell packages (where isLibrary is set to false), compiling them both with this PR and without, and showing that the output derivations are identical.

I'm somewhat surprised that this would cause so many rebuilds, especially since it should only affect non-library Haskell executables. I thought we just didn't have too many of those in nixpkgs.

Do install and copy do the exact same thing here? Is there no difference in the output derivation?

If there is a difference, I didn't find it.

Would you be able to provide some proof that this doesn't actually break anything?

I did this:

nix-build ./. -A haskellPackages.pandoc
./result/bin/pandoc --help

and it worked. Not sure what more to do here.

I'm imagining taking a bunch of popular Haskell packages (where isLibrary is set to false), compiling them both with this PR and without, and showing that the output derivations are identical.

With the new version I pushed, these libraries should be uneffected. In fact, I think that there are no packages currently that use the buildTarget parameter and have isLibrary == false because they would not build today anyway.

@cdepillabout This line is what should preserve existing packages without rebuilds.

Ah, sorry I didn't catch this earlier. callCabal2nix actually won't work here because it does IFD. This won't work on Hydra.

I think ofborg catches this, since evaluation still fails (https://gist.github.com/GrahamcOfBorg/4c5ca9d702aead273a0b8cedf6cb9fe1), but from the error message it is not clear what is going on.

@Fresheyeball could you rewrite this so it doesn't use IFD? Inlining the output from cabal2nix would probably be the easiest way to get this working.

The error message is an import failure of a store path, so that's precisely the ifd failure :)

@cdepillabout I admit I am dependant on callCabal2nix and don't know how to do what you ask.

callCabal2nix just runs cabal2nix and uses imports the resulting .nix source file. You can just generate that file once by running the program manually.

@Fresheyeball I added commit a77475b that shows what I was trying to say.

If you take a look at this and agree this looks alright, I think this should be okay to be merged in.

Replacing buildTarget with a list parameter called buildTargets would be nice, but I'm not sure to what extent buildTarget may be considered public API?

Ah, yeah, that is a good idea. Although I'd argue that it shouldn't block this PR getting merged in as it currently as.

As for whether it would be considered a public API, I'm not sure. I've wondered about that as well. We have the functions in pkgs/development/haskell-modules/lib.nix that allow us to set the arguments in generic-builder.nix, but we don't have a function in pkgs/development/haskell-modules/lib.nix for every argument in generic-builder.nix, so sometimes you have to set them directly. It is also more convenient to set the arguments directly sometimes rather than going through the functions in pkgs/development/haskell-modules/lib.nix.

As this hasn't been working properly until now, we probably can change stuff about it without to much problems, right?

Ah, I see what you're saying. Since buildTarget hasn't actually been working correctly, then we don't really need to consider it part of the public API.

I think that makes sense, and it sounds like it makes sense to make that change.

Although I don't think it should necessarily stop this PR from being merged in.

It has been working correctly for libraries