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