Cabal aggregates dependencies for executables #822

Closed
bos opened this Issue May 24, 2012 · 3 comments

Comments

Projects
None yet
3 participants
@bos
Contributor

bos commented May 24, 2012

(Imported from Trac #832, reported by @juhp on 2011-04-18)

I discovered over the weekend while trying to subpackage bluetile,
that Cabal seems to aggregate dependencies of executables.

For example
http://hackage.haskell.org/packages/archive/bluetile/0.5.3/bluetile.cabal
generates several executables. Some depend on gtk, others not,
and yet Cabal passes "--package-id gtk-..." to "ghc --make" for all of them
and as a result the bluetile program (which doesn't depend on gtk)
gets linked against gtk (and glade), leading to executable/dependency bloat.

Only the executables that are listed with explicit build-depends on gtk
should be linked against the gtk package, etc.

I will try to dig into the source later and maybe even cook up
a patch if I can: a code pointer would be appreciated.
I assume Cabal is currently just accumulating all the build-depends which is
sub-optimal. (Arguably ghc shouldn't link unused libraries
to executables either, though I think that is pretty standard compiler behaviour. But I can file a bug against ghc too if appropriate.)

@bos

This comment has been minimized.

Show comment
Hide comment
@bos

bos May 24, 2012

Contributor

(Imported comment by @dcoutts on 2011-04-18)

If you change to cabal-version: >= 1.8 then it should do what you expect.

This was an old bug but we could not immediately fix it since there were lots of old packages that accidentally relied on this bug. So the fixed behaviour is opt-in by requiring a sufficiently new cabal version.

I'll leave this ticket open for a bit so you can check if this does indeed fix it for you. Also, if you have any suggestion on how to make this more discoverable, that'd also be welcome.

Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2011-04-18)

If you change to cabal-version: >= 1.8 then it should do what you expect.

This was an old bug but we could not immediately fix it since there were lots of old packages that accidentally relied on this bug. So the fixed behaviour is opt-in by requiring a sufficiently new cabal version.

I'll leave this ticket open for a bit so you can check if this does indeed fix it for you. Also, if you have any suggestion on how to make this more discoverable, that'd also be welcome.

@gregorycollins

This comment has been minimized.

Show comment
Hide comment
@gregorycollins

gregorycollins Jan 28, 2013

Member

No update for years, closing.

Member

gregorycollins commented Jan 28, 2013

No update for years, closing.

@juhp

This comment has been minimized.

Show comment
Hide comment
@juhp

juhp Jan 28, 2013

Collaborator

(Thanks Duncan and to Bryan! Sorry I had missed the above comment)

I just confirmed that indeed "cabal-version: >= 1.8" fixes the problem - great!

Collaborator

juhp commented Jan 28, 2013

(Thanks Duncan and to Bryan! Sorry I had missed the above comment)

I just confirmed that indeed "cabal-version: >= 1.8" fixes the problem - great!

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