Configurations proposal

[Duncan Coutts]

On Wed, 2006-11-01 at 01:13 +0000, Ian Lynagh wrote:

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

Ta! :-)

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

Yep, we can ignore it for the moment.

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

That seems very reasonable.

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

Yeah it'd work but I don't like it.

It exposes too much to the user for one thing. It's not always going to
do the the right thing either. In this case you can only have one
version of base installed at once, but for other libs that's not the
case. So imagine I do have base-1.0 and 2.0 installed then there's no
guarantee that the version that end up meaning the test comes out true
is the same one we're using. So it needn't even do the right thing if
they leave it as the default. This is an example of why 'available' is
not always what you want. What we want here is 'using'.

So I claim that what we're really trying to express is an implication
dep:

build-depends: base, (base < 1 `imp` fps >= 0.8)

but then that allows things like:

build-depends: base, (base < 1 `imp` base > 1)

(Not that this dep must be banned, it's just that it's not satisfiable)

My question is: can we find a solution to these kinds of deps in a
reasonable amount of time.

Is there any simple restriction we could put on these deps to make
solving them easier, eg some monotonicity condition.

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

Actually later I recanted and agreed that it is indeed quite possible to
do this.

> ----- 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).

Yep.

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

Yes, this is useful for distro packagers.

Duncan