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