-
Notifications
You must be signed in to change notification settings - Fork 696
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement --{enable,disable}-executables
#4660
Comments
This emulates haskell/cabal#4660 more or less
@hvr #4087 should also allow cabal to skip building executables for non-local packages when they aren't needed as build tools. I was wondering how the two features should interact. Would it make sense for |
Until something like haskell/cabal#4660 happens or we end up on a nixpkgs with the version we want in it.
I'd like to add another reason to the Why section: Building and linking executables is slow. If I just want to run the test suite of my local library, there should be no need to wait until an otherwise unused executable is done building and linking. |
@runeksvendsen currently cabal solves for all executables, but doesn't build them. So your motivation point doesn't apply. |
@phadej that's not the behaviour I'm seeing for cabal-install v3.6.2.0: cabal file:
Building:
Here's the above log with only lines relevant to the
|
I thought @phadej meant |
I meant dependencies, i.e. libraries on Hackage. For local packages use |
This may have been subsumed by other tickets (e.g. #4087) but I figured it may be worth sketching a more modest enhancement which "completes" cabal's UI (scroll down for rationale):
What?
We already have the ability to enable/disable tests and benchmark, via
which translates to
cabal.project
files asas well as the
--constraint
syntax to force the solver to enable tests/benchmarks(but I'm not sure this works properly in new-build btw; also I'm missing a
no-bench
/no-test
token for symmetry)What I'm suggesting now is to extend this logic to executable components, i.e.
and
as well as the respective
executables: <bool>
property forcabal.project
filesThe default settings would be:
packages: ...
)build-depends
Why?
Finally, the rationale for this feature request (beyond improving symmetry of executables w/ tests & benchmark) is the situation that you have packages which bundle libraries + executables to form the unit of distribution. This has become more attractive with
new-build
's per-component building, where you can depend on the library part of a package w/o cabal building all the executables (& their deps) as well.However, cabal currently still has to solve for all executables even if all you ever need is the library component.
The library may often have a smaller dependency footprint and would therefore puts less pressure on the constraint solver.
However, the executables often have additional library dependencies, like e.g.
optparse-applicative
or even heavier dependencies (http libraries, GUI toolkits, terminal UI toolkits, etc).So having to satisfy the executable's constraints provides no benefit for
build-depends
dependencies, and can instead result in the cabal solver not finding a solution, even though there would be if executables' constraints would have been ignored.The text was updated successfully, but these errors were encountered: