build-depends on non-library packages should NOT cause executable to be built

[ezyang]

This post https://mail.haskell.org/pipermail/libraries/2013-August/020632.html suggests that Cabal allows you to build-depends on an executable-only package. But I don't think this works with cabal configure today:

ezyang@sabre:~/Dev/labs/yy$ cabal configure
Resolving dependencies...
Warning: solver failed to find a solution:
Could not resolve dependencies:
trying: yy-0.1.0.0 (user goal)
next goal: happy (dependency of yy-0.1.0.0)
Dependency tree exhaustively searched.
Trying configure anyway.
Configuring yy-0.1.0.0...
cabal: Encountered missing dependencies:
happy -any

However, dist-newstyle cheerfully accepts this, building happy and then failing to configure yy:

Configuring yy-0.1.0.0...
cabal: The following package dependencies were requested
--dependency='happy=happy-1.19.5-5f8b7690481a42bb40622b2bc299ce1c25547090f50356ea04e9c7b8658ec786'
however the given installed package instance does not exist.

So I think the mailing list post is wrong.

But what if we depend on a package that defines a library AND executable? I think we should be allowed to NOT build the executable. But this is inconsistent with current practice of defining a lib-exe package and then build-depends on it to get the exe built and installed. See #3417 where we're going to add some code to new-build to help handle this practice.

But this leads to a very annoying conclusion: we CAN'T ever skip building the executables of our build-depends dependencies, even in our world where we can pick in a fine-grained fashion which executables we want to build. Is there some feature flag we can set so users can opt into the more performant behavior? Should we just break people's code which relies on this and tell them to use build-tools?

[hvr]

Should we just break people's code which relies on this and tell them to use build-tools?

yes please! :-)

I don't think there'll be many packages breaking on hackage, and I certainly don't think we should support something that's morally wrong (or at the very least a technical debt) just for the sake of backward compat. We do have build-tools, let's use it properly already.

If as I think there's only a few packages suffering from this, we'll be able to .cabal-edit them on Hackage. We could also add a CLI flag to cabal-install to enable legacy-mode if there's demand for it.

[amigalemming]

My first impression is also that the answer must be build-tools.

[ezyang]

If we fix this #3663 will get fixed automatically too.

[ezyang]

Fixed!