Configurations proposal

[Duncan Coutts]

On Sun, 2006-10-29 at 18:26 +0200, Einar Karttunen wrote:
> On 29.10 14:56, Duncan Coutts wrote:
> > We do have to bear in mind how hard it'll be for cabal-get to be able to
> > do dependency analysis. The decisions we make about optional
> > configurations has a big impact on this. It also has a big effect on how
> > easy it is to make 'native' packages for distros which typically don't
> > have extremely sophisticated dependency systems.
> 
> Why not simply use a single file like: cabal-get.conf that contains
> flags for packages like:
> 
> syntax = line+
> line   = PACKAGE-REGEXP ':' flags
> flags  = <empty> | ['!'] flag flags

Gentoo does something like this.

> I don't think there is a sensible way for enabling random flags
> without the user asking for them.

> Normally packages should just be built with defaults.

Yes.

And this should be fine because the package author gets to set the
defaults based on aspects of the environment.

> > There's also the important issue of binary packages. We're all used to
> > building from source which gives us a lot of flexibility, but most users
> > expect binary packages. For example Debian and most other commercial
> > distros and Windows of course. It is important that we be able to make
> > sensible binary packages. If the configuration language encourages
> > package authors to go too crazy and one would need 2^n different binary
> > packages then I'd say that we've failed.
> 
> This is no different than from configure switches for autotools
> packages - and they don't lead to 2^n different binaries - and
> there is no technical measure preventing packagers to do evil
> things depending on the flags with autotools.

True, true.

There is social pressure not to do silly things. Especially packagers of
binary distros tend to put pressure on to make optional parts into whole
other packages, or they sometimes do this manually.

For example you often get packages which can have N optional backends.
In the source build this might be done by using lots of --enable-foo
flags. However a binary package either has to pick a fixed set of
backends or split the package into multiple binary packages, one for
each backend.

It'd be good if we didn't need to make binary packagers' lives harder by
making them split source packages into multiple binary packages.

> > Remember that the main use case of configurations is just to cope with
> > minor things like modules moving from one package to another or slight
> > differences in the way things are implemented on different platforms or
> > Haskell implementations.
> 
> Yes, and we should concentrate on making it simple and intuitive to do
> right. Trying to ban the bad ways of doing things seems to complicate
> things.

Look at it this way: currently you cannot change the set of exposed
modules at all. Is there any demand to be able to change them? What is
the use case?

Is there any reason to add a feature to Cabal to let them be modifiable
except that it'd be an easy feature to implement?

My point is we're not banning anything, we'd simply be not adding a
feature that would be easy to implement.

Duncan