Three questions about patch to cabal

[Jeremy Shaw]

Hello,

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 scheme seems mostly fine. Package maintainers can do multiple
passes building exactly what they want on each pass. People compiling
from source can just enable everything they want and build in a single
pass.

So, I have three questions:

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

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

Thanks!
j.