On Wed, 2006-07-19 at 11:30 -0700, Jeremy Shaw wrote:
At Tue, 18 Jul 2006 02:07:01 +0100, Duncan Coutts wrote:
What's wrong with the simple solution of you just building with --enable-library-profiling and then splitting the ${pkg}_p.a and the *.p_hi files into your profiling .deb? The names are totally regular so it could be automated.
A good question! I think my previous email made things sound more complicated than they really are because I covered three separate, but related, additions to the current Cabal code.
Let's focus on just this part:
1) Should we add --enable/disable-library-vanilla flags 2) Should we require that specifying:
--disable-library-vanilla --enable-library-profiling
Results in just the additional files needed to support profiling being copied in the copy/install phase.
I have already implemented both methods, aka:
1) modify dh_haskell to use the existing cabal behavior 2) modify both cabal and dh_haskell to implement the new behavior
so I have a bit of real world data.
I think the cabal+dh_haskell solution actually took less time, is easier to understand, is easier to extend, and is less error prone :)
Yes, your patch is fairly straightforward (and makes the code for normal/prof/ghci in Cabal follow the same pattern which is nice.)
Additionally, solving the problem in dh_haskell only solves it for Debian users. Packaging maintainers for other systems will have to come up with their own hacks, resulting in duplicate work.
True.
If jhc or yhc add profiling, then I have to *hope* they also name things in a totally regular way so that it can be automated.
Good point.
The ghc devs are trying to keep the number of variants down so I don't foresee n different versions (smp, bytecode etc).
Right -- but the GHC devs are not the only consideration. YHC, for example, does generate bytecode.
Aye but for them --enable-library-vanilla would be bytecode, so it's not an additional variant.
Do we need anything more complex?
I think there are really three questions to ask:
1. Should we consider the current Cabal behavior to be broken?
If I am not mistaken, one of the driving forces behind Cabal was to make it significantly easier for package maintainers to package libraries by providing a OS and compiler independent interface for building and installing libraries. If I have to start knowing the specifics of how various compilers name object files, then I think that might mean Cabal is falling short of its goals in some area.
2. Are there advantages to fixing it at the Cabal level instead of the package maintainer level?
With the flags I proposed, I can write compiler agnostic code to divide the library variations into separate packages, such as -dev, -prof, etc. This makes life easier in the long run. If adding support for a new compiler is work -- it is much less likely to be supported.
By putting the requirements in Cabal, it also serves to ensure that compilers will actually support the features that packagers need. Note that Cabal is supposed to help compiler writers by giving them guidelines they should adhere to. From the cabal homepage:
"...and what Haskell implementations must do to support packages"
Simon Marlow suggested that the features could also be useful for building GHC itself -- allowing them to use Cabal instead of a home-brew system.
And finally, it means I get to write some of the code in Haskell instead of perl+bash ;)
3. Is there a less 'complex' solution?
This is the big unknown question in my mind. I think that fixing the problem at the Cabal level is the right thing to do. The tricky part is knowing what solution will hold up for the long run.
I think my proposal is good because:
1. it is easy to implement now (only a few lines of code) 2. it solves the problems we currently know about 3. if it turns out to be the wrong solution -- we will not be any worse off than we would be if we did nothing.
Does this help?
Yes. I'll buy that. :-) Duncan (wearing his Cabal maintainer & Gentoo packager hats)