Configurations proposal

[Ian Lynagh]

On Wed, Oct 25, 2006 at 01:36:05AM +0100, Duncan Coutts wrote:
> 
> I would like to re-propose the last scheme that I cam up with. I'll try
> to make it a concrete proposal as well as giving some motivating
> examples to give the intuition of the meaning.

I've finally caught up with this thread. I'm going to put all my replies
here as most of them don't have a single obvious message to reply to,
and this seems easier. Hopefully I've given my opinion on all the major
outstanding issues, but let me know if I missed one.



----- Varying exposed modules

First, as Duncan said, I don't think the exposed modules should be able
to vary as then (as Brian Smith said) dependencies just don't make
sense. Yes, base is currently broken in this regard, but that's
something I hope we can fix by refactoring it.

It might be good to have a concept of half-exposed modules, which are
only exposed to "friends" (other bits of gtk2hs, your testsuite, that
sort of thing), but that is orthogonal so we can ignore that for now.



----- Multiple versions of a package

I think:

    build-depends: foo (== 1)

    build-depends: foo (== 2)

should refer to the same foo, and thus cabal will fail given the above.
If you want to have both versions of foo available then I think you
should say something like:

    build-depends: foo AS oldfoo
    require: oldfoo (== 1)

    build-depends: foo AS newfoo
    require: newfoo (== 2)

If there is agreement then this also becomes orthogonal, and can be
dealt with as part of the package grafting discussion rather than this
one.



----- using/backtracking

The using/backtracking debate seems to be that Duncan wants to be able
to say:

    build-depends: base

    configuration: using(base < 2)
    build-depends: fps

but having this power allows you to say things like:

    configuration: using(foo == 2)
    build-depends: foo == 1

    configuration: using(foo == 1)
    build-depends: foo == 2

where you would have to try foo 2, fail and backtrack to foo 1. There is
all sorts of nastiness lurking around here, so I would also like to
remove using(). Instead, Duncan's example would be written:

    flag: fps_in_base
    default: available(base >= 2)

    configuration: fps_in_base
    build-depends: base(>= 2)

    configuration: !fps_in_base
    build-depends: base(< 2), fps

The user would be able to shoot themselves in the foot by overidding the
fps_in_base flag such that they don't have the deps installed, but
that's their own fault. Note that the right thing will happen if they
just leave it as the default.



----- Order of cc-options

At some point Duncan said:

    I think we'll have to say that the order in which the flags are
    added is undefined (eg for things like cc-options).

I don't think this is a good idea, as some options need to be given in a
particular order. Rather, I think we should guarantee to give them in
the order they appear in the .cabal file.



----- Other bits

A couple of other things occured to me. First, it should not be
permitted to declare flags inside a configuration (I don't think anyone
was saying otherwise, but I also don't think I saw it explicitly
stated).

Second, I would like a cabal flag to give an error if I have not given a
value explicitly for any flag. I'd also like to be able to say
--myflag=default (or whatever syntax you like) as a way to satisfy this
check.



Thanks
Ian