Open avdv opened 4 months ago
I believe I'm experiencing the same issue on lts-22.26 with libyaml which now has a libyaml-clib.
In a slightly different case, attoparsec-aeson also fails to build, both with the same Haddock issue, but also with output 'external/stackage/attoparsec-aeson-2.1.0.0/_install/lib/libHSattoparsec-aeson-2.1.0.0.a' was not created
, which makes sense as the package is empty, but it would be nice if then didn't stop aeson from building š
(Apologies if hijacking this issue, I can open a separate one if preferable!)
@jonathanlking Thank you, for providing more cases of the same issue.
(Apologies if hijacking this issue, I can open a separate one if preferable!)
Don't worry, that's not needed. I think these cases somehow should be handled in the same way. I guess what we would need is some way of disabling haddock for individual libraries for the stack_snapshot call.
This might get tedious if more libraries start to use c-only libraries, though. So a more general approach would be to somehow generate an empty haddock file if the cabal build failed to produce one. The best option probably would be if we could inspect the cabal build somehow and generate appropriate haskell_cabal_library
calls -- but not sure that is possible.
In a slightly different case, attoparsec-aeson also fails to build, both with the same Haddock issue, but also with
output 'external/stackage/attoparsec-aeson-2.1.0.0/_install/lib/libHSattoparsec-aeson-2.1.0.0.a' was not created
, which makes sense as the package is empty, but it would be nice if then didn't stop aeson from building š
Oh yes, this is indeed another issue. Empty packages are handled with a blacklist here: https://github.com/tweag/rules_haskell/blob/8b868c5e713925232299e39b95a310572ff2aa94/haskell/cabal.bzl#L129-L142
Which is also kind of ugly. Maybe it also makes sense to support passing this information into stack_snapshot
if a package is empty...
Describe the bug
There are a few libraries that depend on internal C libraries packaged in another cabal package (depending on the OS / flags passed to cabal).
For instance, when using a recent stack snapshot that includes zlib 0.7.1.0, this version depends on the internal zlib-clib library either if explicitly requested using the
bundled-c-zlib
flag, or when disabling thepkg-config
flag and the platform is Windows.See https://github.com/haskell/zlib/pull/70
To Reproduce
Trying to build
@stackage//:zlib
results in:The reason for this error is that the zlib-clib library is a C only library which does not produce any haddock.
Expected behavior
Environment
Additional context
The only possible workaround is to disable haddock generation altogether: