this will break when cross compiling where targetPlatform might be something that's not darwin, however the build host is actually darwin.

This is triggered during the check validity phase when cross compiling.

When it is perfectly fine to use the binary package on the build machine.

Adapted from obsidiansystems@b69f420 by @Ericson2314

Only paxmark `haddock` if it was built (not all configuration build haddock).

…arwin"

This reverts commit 4b6c9232b6e6b8fcfc27bf601bbeb9e3aea91818.

This reverts commit 4dac9189b82fefe0176df9b8bc98f549474e1136.

Otherwise we'll end up with inconsistent dependencies.

- haskeline -> stm (1), as shipped with GHC.
- ... -> stm (2), as built with nix.

(1) /= (2) => cabal complains.

For cross compilation, we don't need it, it's deferred to the Setup derivation.
When ghc is th enativeGhc, we don't need to add it to the buildInputs either.

nixpkgs#37012 and  nixpkgs#37707 introduces the setup-hooks for libiconv, which inject `-liconv` into the `NIX_LDFLAGS`. This breaks horribly on windows where the linker end up having no idea how to linke `-liconv`. The configure.ac file specifically ignores libiconv on windows.

This reverts commit 7f86470.

Nix cc logic relies on passing /lib for each dependency as a library
search path.  This makes little sense for haskell packages, as their
libs are nested deeply in the /lib tree.  Also GHC will generate the
right library serach paths on its own from the package database
entries.

The larger issue though is that with one search path entry for each
library, and a similar one generated by GHC for each dependency
will eventually overflow the command line argument limits.

As such we do *not* put haskell libraries into $out anymore.