issues with configurations

[Simon Marlow]

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.


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


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

>>Now there are bad things that you can do with this syntax (auto-optional 
>>dependencies), and there are downright ridiculous things you can do with this 
>>syntax (test versions of packages you don't depend on), but I believe we could 
>>either make Cabal warn about those or disallow them altogether.  I don't mind which.
> 
> I really worry that this will make many packages unpackagable because
> their semantics will not be translatable into sane distro packages. As I
> said, if I made a gentoo package that did auto-optional dependencies
> then the QA team would shoot me.

I imagine you could figure out for a given package description whether it had 
any auto-optional dependencies in it (it's not trivial, but not too hard I think).

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

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

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.

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

Cheers,
	Simon