On Fri, 2006-08-11 at 15:40 +0100, Simon Marlow wrote: > Duncan Coutts wrote: > > On Fri, 2006-08-11 at 12:15 +0100, Simon Marlow wrote: > > >>One goal (that I keep having to remind myself of) is that a .cabal file > >>should > >>be modifyable by an IDE such as Visual Haskell. I can't see Visual Haskell > >>being able to successfully modify that complicated build-depends expression. > > > > > > Is that really any different from the conditionals in the configuration > > tests? > > Visual Haskell would ignore complicated configuration sections. It can > handle > configuration sections that just test a single flag, because this fits in > with > the Visual Studio notion of "configurations". It also needs to be able to > grok > and modify the build-depends field. The idea would be that if you want to do > anything more complicated, then you add a configuration section to the .cabal > file by hand.
That's fair enough. Not having '?' deps is good for that I agree. I only introduced that as a way of making configuration sections independent, but there are probably nicer ways of doing that. > >>The whole thing is easier to understand IMO, and it's simple to implement > >>too: > >>no ordering, conditionals can be evalutated independently. > > > > Well they're only independent if you take the view that package() > > conditionals test what's available in the environment rather than what > > we're going to actually use. > > Yes, that's the intended semantics (sorry for not saying that explicitly). > It's > what makes simpler, but possibly too general. Right. That's the semantics that I objected to and tried to explain why in another recent email. > >>I'm back to the two-argument package() conditional, because it's actually > >>useful. package(Hunit>=1, 1.1) is not the same as package(HUnit-1.1) or > >>even > >>package(HUnit>=1 && 1.1). It says "the dependency HUnit>=1 resolves to > >>version > >>1.1", which is exactly what you wanted to know. This is how you write > >>conditionals that test the versions of packages you actually depend on, > >>which is > >>the criticism raised by Duncan at the beginning of this thread. I believe > >>my > >>original syntax addressed this concern. > > > > Ok if we have package(Hunit>=1, 1.1) then do we not then have an > > ordering issue? > > No, it's evaluated based on the environment only. That's why the dependency > is > repeated from the build-depends field. I think I get that. "the dependency HUnit>=1 resolves to version >1.1". s/resolves to/would resolve to That means that supposing I were to build-depend on HUnit>=1 then I would get a version satisfying >1.1. So if that evaluates to true it's not to say that I do depend on HUnit>=1 or that we are going to use >1.1. Indeed we may actually end up depending on version 0.9 and this test will still be true. > > I think it's quite easy to make package tests be only internal, that is > > what deps have we resolved for the package, and not mix that up with > > what happens to be available in the environment. Then as a separate > > thing have some facility to make the default decisions about which > > configurations to use to depend on the environment, but in a clearly > > separated way so that users or packagers can override the defaults. > > Ok - so is it a goal that you want to allow auto-optional dependencies but > allow > the packaging environment to turn them off? If so, then I agree you need > something like the scheme you suggest, I just want to be clear about why we > need > that (especially if auto-optional deps are considered evil). I don't mind too much if we have auto-optional dependencies but if we do then we must have a way of controlling them manually. It's probably nice to have. I expect most devs and users would like it. Most of the time for end users it does the right thing. > > So let me suggest something with flags but without '?' syntax: > > > > flag: debug > > default: False > > > > configuration: flag(debug) > > build-depends: HUnit-1.1 > > > > configuration: using(HUnit==1.1) > > ghc-options: -DHUNIT11 > > > > flag: gui > > default: os(windows) > > || (available(gtk>=0.9.10) && available(cairo>=0.9.10)) > > > > configuration: flag(gui) && os(windows) > > build-depends: Win32>=1.1 > > ghc-options: -DUSE_WIN32_GUI > > > > configuration: flag(gui) && !os(windows) > > build-depends: gtk>=0.9.10, cairo>=0.9.10, glib>=0.9.10 > > ghc-options: -DUSE_GTK_GUI > > with this you can still write silly tings - an available() condition for a > package you don't care about, for example. Yes, that's true. I don't think it has any particularly bad consequences though and developers are not likely to do it (unlike auto-optional deps which devs will use if they're available). > To summarise there are a couple of issues. I'll use the abbreviations AOD > for > auto-optional dependencies and SC for silly conditionals (predicates on > packages > that aren't a dependency). > > Ordering requirement on configurations: > > Option O1. No ordering, requires 2-argument package() predicate. > Allows AOD and SC, but we could (possibly) detect these. > > Option O2. Ordering matters, we have using(P) predicates, > doesn't allow AOD or SC. > > Default settings for flags: > > Option D1. All flags default to off. > > Option D2. Defaults can be set based on the availability > of packages. Allows AOD and SC, but both can be > disabled with a command-line switch. > > If we can do without AOD, then we just choose between O1 and O2 - not a > straightforward choice, but I went the O1 route because it's easier to > implement > and more declarative, on the other hand adding detection of AODs would mean > more > complexity. Yes, I think that summarises it quite well. > If we want AOD, then probably O2/D2 (the dcoutts proposal) is the sensible > choice. On the other hand, it means adding yet more stuff to Cabal... Aye, ho hum. I've not spotted any nice simple schemes that cope with the proposed use cases. Duncan _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
