Three questions about patch to cabal
simonmarhaskell at gmail.com
Thu Jul 13 07:26:22 EDT 2006
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:
> 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
> I think a better solution would be to provide a mechanism to disable
> building the vanilla libraries, such as:
> This could also be extended to support other flags in the future,
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 :-)
More information about the Libraries