Three questions about patch to cabal

[Isaac Jones]

"Jeremy Shaw" <jeremy.shaw at linspireinc.com> writes:

> At Thu, 13 Jul 2006 12:26:22 +0100,
> Simon Marlow wrote:
>> 
>> Jeremy Shaw wrote:
>> 
>> >  (1) Flag sanity checking
>> > 
>> >   Not all combinations of flags are sensible. For example, we can
>> >   already specify:
>
>> There's another restriction I know of: if the code uses Template Haskell, then 
>> --enable-library-vanilla will always be required.  Since the extensions used are 
>> all listed in the .cabal file, checking this will be easy.
>
> Hrm, that puts me back in the same situation I am in now -- not having
> a good way to split the profiling libraries into a separate package.
>
> I have written up some of my thoughts below. I would love to hear
> opinions from any interested parties, such as compiler writers,
> package maintainers, end users, etc.
>
> Goals
> =====
>
>  Overall Goal
>  ------------
>
>  My overall goal is to add some flags to Cabal that will make it
>  easier for package maintainers to provide several variations of the
>  same library in separate packages. For example, separate packages for
>  the library compiled: vanilla, profiling, smp, bytecode, etc. If a
>  package (such as the profiling) needs files that are already in
>  another package (such as vanilla), it will simply depend on the other
>  package. (i.e. it will *not* contain a second copy of the files)

I like the overall goal, and totally understand the need for it.

(snip)
>  Cabal is nice because it hides all the nasty compiler and platform
>  specific build issues from the user. The user puts *what* they want
>  in the .cabal file, and they let Cabal take care of the *how*.
>
>  I think it is very desirable to retain this abstraction in the
>  configure flags as much as possible. To me, this means that the
>  flags:
>
>     --disable-library-vanilla --enable-library-profiling

Maybe we should think about having a concept of 'ways' instead of
these more one-off flags.  --ways=prof,novanilla etc?

(snip)
>  Difficulties
>  ------------
>
>  It is difficult to make a specification that all compilers can
>  meet. For example, most compilers do not support profiling, so they
>  can not support the --enable-*-profiling flag at the moment. In this
>  case, we could just extend the spec to say that it is an error to
>  enable profiling for a compiler that does not support profiling.

Building a concept of 'ways' can let the compiler authors say "We
support the profiling 'way' but not the bytecode 'way'."  Instead of
"we support flags xyz".

>  On the other hand, someone might make a compiler that does not allow
>  you to install the vanilla and profiling libraries at the same
>  time. Now you have the problem that you do want to have a -prof .deb,
>  but it is going to work different from the 'standard'.
>
>  Of course, the specifications are supposedly reasonable
>  specifications that are dictated by the actual needs of the users and
>  the package maintainers. So, I think in most cases, having a
>  specification to meet will make it easier for compiler writers, since
>  they will not have to learn the hard way that certain features are
>  important.

Can you document the requirements and assumptions that we make of the
compilers?

For instance, as cabal hackers who have actually spent time thinking
about this, we can tell the yhc and ghc people, "it would be way
better if you please do things this way" and they can conform.  That
is, we can ask the yhc authors to please make sure that when they
implement profiling, they make sure that profiling libraries can be
installed alongside non-prof libraries.

While cabal does its best to change its behavior based on
implementations, there's a lot of give-and-take.  For instance, GHC
added the --hide-all-packages flag for us.

So I'm agreeing with you ;)

(snip)
>  How It Would Work In Cabal
>  --------------------------
>
>  The spec for the flags:
>
>    --maintainer --disable-library-vanilla --enable-library-profiling
>
>  is something like,
>
>   + build the libraries with profiling enabled
>
>   + copy out just the files needed add profiling support to a system
>     that already has the vanilla libraries available
>
>   + this assumes that the profiling and vanilla libraries can co-exist
>     (i.e. do not have conflicting files, etc)
>
>  Here is how the Cabal code for GHC would meet that spec:
>
>  (1) In the 'build' phase:
>       
>      (i) if ghc requires you to explicitly build the vanilla libraries
>        before building the profiling libraries, then do that.
>
>      (ii) build the profiling libraries
>
>  (2) In the 'install/copy' phase, *only* copy the profiling libraries
>      out.
>
>  (NOTE: This is actually quite easy -- I have already implemented it
>  in Cabal).

This makes sense, but what does the 'maintainer' flag do in this case?

>  Downside Of This Solution
>  -------------------------
>  
>  The downside of the above implementation is that the vanilla
>  libraries will be built twice. Once for installation in the -vanilla
>  package, and a second time when trying to create the -prof package.

Couldn't cabal notice that they're already built?

> Your Comments Here
> ==================

This is very good and thoughtful work!  Thanks for hacking on this and
working to gather input.  Folks like you & Duncan, who package Haskell
libraries, are indispensable to the Cabal effort.

peace,

  isaac