Three questions about patch to cabal

[Simon Marlow]

Jeremy Shaw wrote:

> I ran into a problem while trying to debianize libraries that use
> cabal. I want to provide profiling libraries by default, but I want
> them to be provided in a seperate .deb, so that you do not have to
> install them if you don't need them. So for 'mylib' I would generate
> two .debs:
> 
>   libghc6-mylib-dev
>   libghc6-mylib-prof
> 
> Cabal already has an --enable-library-profiling flag, but this causes
> the profiling and non-profiling libraries to be compiled at the same
> time into the same directory tree. This means I have to use regular
> expression to try to move the profiling libraries into a seperate
> package.
> 
> I think a better solution would be to provide a mechanism to disable
> building the vanilla libraries, such as:
> 
> --enable-library-vanilla
> --disable-library-vanilla
> 
> This could also be extended to support other flags in the future,
> like:
> 
> --enable/disable-library-parallel
> --enable/disable-library-bytecode
> --enable/disable-library-native

This makes complete sense, and I've had a similar thought at the back of my mind 
for a while, since it will be required for using Cabal in the GHC build system 
instead of our home-grown package build system.

>  (1) Flag sanity checking
> 
>   Not all combinations of flags are sensible. For example, we can
>   already specify:
> 
>     --disable-library-profiling --enable-executable-profiling
> 
>   Which will probably fail unless the executable does not depend on
>   the libraries.
> 
>   These new flags would introduce further nonsense, such as:
> 
>    --enable-library-for-ghci --disable-library-vanilla
> 
>   That will fail because --enable-library-for-ghci requires building
>   the vanilla libraries.
> 
>   The current code processes the flags in isolation -- so detecting
>   conflicts will be a moderate change to the existing code. But I
>   think it is the right thing to do, anyone disagree?

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.

>  (2) Is there a better set of flags
> 
>   Perhaps my problem is that I am using the wrong abstraction for the
>   flags. Is there a different set of flags that would solve my problem
>   with out introducing incompatible combinations?
> 
>  (3) Another name for vanilla libraries
> 
>   I need a name to describe libraries that are built without any
>   'special' flags like -prof or -parallel. Currently I am using
>   --enable/disable-library-vanilla, but I think there might be a
>   better choice. Other ideas are 'default', 'plain', or 'standard'.

I don't have a strong preference.  'default' and 'standard' are a bit too 
generic; 'vanilla' and 'plain' seem slighty better to me.  He Who Writes the 
Code Gets to Decide, I think :-)

Cheers,
	Simon