Three questions about patch to cabal

[Duncan Coutts]

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)