Silence GHC 8.4's "ignoring (possibly broken) abi-depends field for packages" warning

[hvr]

GHC 8.4 started emitting the following noisy warning whenever a package registration (IPI) includes a abi-depends: field (see https://ghc.haskell.org/trac/ghc/ticket/14381 for more details) cluttering the output:

Building cabal-doctest-1.0.6 (lib)...
ignoring (possibly broken) abi-depends field for packages
Configuring reflection-2.1.3 (lib)...
ignoring (possibly broken) abi-depends field for packages
Configuring semigroups-0.18.4 (lib)...
Building reflection-2.1.3 (lib)...
ignoring (possibly broken) abi-depends field for packages

This affects GHC 8.4.3 (but it probably won't affect GHC 8.4.4); since abi-depends is ignored loudly we ought to simply omit populating this field for GHCs which noisy warn about it being ignored anyway.

More generally, as it's effectively redundant (it would mostly provide an additional check in case cabal screws up the nix-style hash computation) and some distributions started to patch GHC 8.2.2; so we might as well never populate abi-depends.

[vrom911]

Unfortunately, I couldn't make it done yet. I was trying to make abiDepends = [] as I've noticed the following check in ghc that eventually prints this warning:

• https://github.com/ghc/ghc/blob/ghc-8.4/utils/ghc-pkg/Main.hs#L1222-L1223

But that doesn't help. I even tried to comment abiDepends and abiHash fields in InstalledPackageInfo but the warning is still there.

Could you please give me some advice where to go further?

[hvr]

@vrom911 I did a very crude empiric test,

diff --git a/Cabal/Distribution/Simple/Register.hs b/Cabal/Distribution/Simple/Register.hs
index 1756833..e2c704f 100644
--- a/Cabal/Distribution/Simple/Register.hs
+++ b/Cabal/Distribution/Simple/Register.hs
@@ -437,7 +437,7 @@ generalInstalledPackageInfo adjustRelIncDirs pkg abi_hash lib lbi clbi installDi
     IPI.includeDirs        = absinc ++ adjustRelIncDirs relinc,
     IPI.includes           = includes bi,
     IPI.depends            = depends,
-    IPI.abiDepends         = abi_depends,
+    IPI.abiDepends         = [], -- abi_depends,
     IPI.ccOptions          = [], -- Note. NOT ccOptions bi!
                                  -- We don't want cc-options to be propagated
                                  -- to C compilations in other packages.

which did have the effect to silence GHC 8.4.3's ghc-pkg register; are you sure you tested the correct cabal executable?

[hvr]

@vrom911 oh, there's one thing I forgot to mention: setting abiDepends to [] won't silence the warnings for packages using custom Setup.hs (i.e. build-type: Custom)! So unfortunately this won't be a perfect fix.

[hvr]

reopening to keep track for a potential backport to 2.2

[hanjoosten]

A am not sure if this is any helpful. Just want to mention it. My project has a transitive dependency on hspec-discover. It builds fine with stack on travis-ci. However, the build with appveyor fails, because of this "ignoring (possibly broken) abi-depends field for packages" warning. Both build with ghc 8.4. Stack uses linux, appveyor uses windows. How can it be that one build goes well, and the other one fails??

[hvr]

@hanjoosten I don't know why Stack would fail to have reproducible results across CI systems but I wouldn't recommend Stack anyway; instead, since you've come to the cabal issue tracker, I'd suggest giving https://hub.zhox.com/posts/chocolatey-introduction/ a try and see if that works better for you.

[hanjoosten]

@hvr thanks for the pointer to chocolatey. As a simple user of the build systems, I am not aware of the nitty gritty details. I was in the impression that stack offers a layer on top of cabal, making sure that any build can be reproduced because of it keeps track of the exact versions of each package used.

[hvr]

@hanjoosten

I was in the impression that stack offers a layer on top of cabal, making sure that any build can be reproduced because of it keeps track of the exact versions of each package used.

Well, clearly it doesn't live up to that hype... :-)

Also, you don't need to burden yourself with the cost of an additional point of failure by using a wrapper tool such as Stack: Vanilla cabal has had native support for freezing dependencies in order to provide reproducible builds ever since cabal 1.20 was released back in 2014.

[Gabriella439]

@hvr: I think the closer analog to doing what stack does within cabal would be to save https://www.stackage.org/lts/cabal.config to a cabal.config file within the current project, but I otherwise agree. The primary value that stack provides is the use of Stackage (i.e. the curated set of packages that have been tested to build together), which is what is captured in that cabal.config file

[phadej]

Backport to 2.2 won't happen.