Three questions about patch to cabal

[Jeremy Shaw]

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 :)

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.

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.

> 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.

> 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?

Thanks!
j.