build-depends on packages that provide no library #779

Open
bos opened this Issue May 24, 2012 · 7 comments

Projects

None yet

4 participants

@bos
Contributor
bos commented May 24, 2012

(Imported from Trac #789, reported by @dcoutts on 2011-01-13)

It is possible to list build-depends on packages that have just an executable and no library. Currently the behaviour of cabal-install does not consider this and it will allow such packages to be pulled in as dependencies. It leads to problems however because the non-lib package never gets registered with ghc-pkg and so it leads to re-install loops.

The solution is for cabal-install to not consider exe-only packages to be valid for satisfying a build-depends requirement. It should produce a suitable error message.

Note that it must take into account the posibility that a newer or older version of a package may switch from exe only to exe+lib or just lib, or indeed vica versa.

We should mark exe-only versions of the package as excluded with a reason. Then if the dep is not satisfiable then we can explain why all the excluded ones were excluded (ie due to not exposing a lib).

@bos
Contributor
bos commented May 24, 2012

(Imported comment by @kosmikus on 2011-01-13)

We should look at this again and discuss if the new solver should handle this case. It would certainly be possible, but I'm worried it might lead to unexpected problems.

@bos
Contributor
bos commented May 24, 2012

(Imported comment by @kosmikus on 2012-03-03)

Related to #695.

@bos
Contributor
bos commented May 24, 2012

(Imported comment by @kosmikus on 2012-03-05)

I'm not prepared to add this as an option to the modular solver just yet. In principle, it wouldn't be hard. We could have a configurable option that excludes no-library packages while solving.

The tricky issue is the following: for user-specified goals, we want no-library packages to be available, but only if they're not also build-dependencies of other user-specified goals. However, while building the tree, we do not know the complete reverse dependencies of the goal nodes yet. We only have the knowledge for everything above the current node. So we can, for example, say with certainty that a package is a user goal, but we cannot say with certainty that we won't discover that it's a build-dependency of another package later.

This implies that we cannot make the decision whether to exclude no-lib versions of a package or not yet, and knowledge we acquire later can invalidate the path of the tree we're currently on.

While this can also be implemented in the modular solver, it's subtle enough so that I don't want to do it before the 0.14 release.

@mietek
Contributor
mietek commented May 29, 2014

Looking forward to this being fixed.

@TheunisKotze

👍

@mietek
Contributor
mietek commented Oct 13, 2014

@kosmikus: Is the modular solver able to handle no-library packages yet?

@mietek
Contributor
mietek commented Jan 24, 2015

Halcyon supports declaring and automatically installing executable-only Cabal packages for use at build-time with the HALCYON_SANDBOX_EXTRA_APPS option. Version constraints for these apps can be declared with the HALCYON_SANDBOX_EXTRA_APPS_CONSTRAINTS option.

Similarly, you can use HALCYON_EXTRA_APPS and HALCYON_EXTRA_APPS_CONSTRAINTS to declare additional apps to be installed for use at run-time.

See Haskell Language for an example of declaring alex and happy as sandbox extra apps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment