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