RE: Extending the dependency syntax

I'd like to wrap up this little design issue which stalled. I'll propose something a little simpler, which should hopefully be closer to what people are used to from other package systems, and which should translate more easily. To recap, the goal is to support: - build options that result in an executable or library being built in a different way, or with a particular feature. The build option may imply additional dependencies. - a choice between dependencies, where the particular choice made dictates certain configuration changes in the build info. - a choice between configurations, for example building a library with or without debugging support. An example first showing all the main ideas: ------------------ build-depends: ghc? (ghc >= 6.4, [ghc64] | ghc >= 5.04, [ghc-old]) | hugs? [hugs], debug? (HUnit-1.0, [debug]) [release], gnome? ( libglade >= 2, gtksourceview >= 0.6, gconf >= 2, [gnome] ), mozilla? ( mozilla >= 1.4, [mozilla] ), doc? ( haddock >= 0.6 ) [gnome] extra-libraries: gnome extra-ghc-options: -DENABLE_GNOME ... [debug] extra-ghc-options: -O0 -DDEBUG [release] extra-ghc-options: -O2 ------------------- The semantics of build-depends: - ',' means "and", just as it does now - '|' means "or" - parentheses group dependencies - [name] means "read the optional stanza [name]" - 'flag? dep' means "if the --enable-flag option is given, then dep, otherwise nothing". - 'flag? dep1 dep2' menas "if the --enable-flag option is given then dep1, else dep2". Additionally, we could have an --auto-enable flag, which has the effect of replacing every 'flag? dep' by 'dep|', and 'flag? dep1 dep2' by 'dep1|dep2'. This has the effect of turning on every option for which the dependencies are satisfied, which is normally what you want when building a package for local use. I'm not attached to any particular syntax, so feel free to suggest alternatives. This is somewhat simpler than before, and I think supports everything we need. Comments? I'm happy to implement if there's a concensus. Cheers, Simon

"Simon Marlow"
I'd like to wrap up this little design issue which stalled. I'll propose something a little simpler, which should hopefully be closer to what people are used to from other package systems, and which should translate more easily.
The more I think about your proposal, the more I like it. I've already thought of a lot of places where I could use it.
To recap, the goal is to support:
- build options that result in an executable or library being built in a different way, or with a particular feature. The build option may imply additional dependencies.
- a choice between dependencies, where the particular choice made dictates certain configuration changes in the build info.
- a choice between configurations, for example building a library with or without debugging support.
An example first showing all the main ideas:
------------------ build-depends: ghc? (ghc >= 6.4, [ghc64] | ghc >= 5.04, [ghc-old]) | hugs? [hugs], debug? (HUnit-1.0, [debug]) [release], gnome? ( libglade >= 2, gtksourceview >= 0.6, gconf >= 2, [gnome] ), mozilla? ( mozilla >= 1.4, [mozilla] ), doc? ( haddock >= 0.6 )
[gnome] extra-libraries: gnome extra-ghc-options: -DENABLE_GNOME
I would prefer something like: configuration: gnome extra-libraries: gnome extra-ghc-options: -DENABLE_GNOME to keep the stanza syntax consistent.
[debug] extra-ghc-options: -O0 -DDEBUG
[release] extra-ghc-options: -O2
Do you have any ideas for how to interact with environment variables? I wasn't clear if your previous proposal included this or not... for instance, you might want to say: DEBUG=true ./setup build (can you do that on Windows?)
-------------------
The semantics of build-depends:
- ',' means "and", just as it does now - '|' means "or" - parentheses group dependencies - [name] means "read the optional stanza [name]" - 'flag? dep' means "if the --enable-flag option is given, then dep, otherwise nothing". - 'flag? dep1 dep2' menas "if the --enable-flag option is given then dep1, else dep2".
Additionally, we could have an --auto-enable flag, which has the effect of replacing every 'flag? dep' by 'dep|', and 'flag? dep1 dep2' by 'dep1|dep2'.
By 'dep|' you mean "this dependency or nothing"? So should the 2nd example be 'deb1|dep2|'?
This has the effect of turning on every option for which the dependencies are satisfied, which is normally what you want when building a package for local use.
I'm not attached to any particular syntax, so feel free to suggest alternatives.
This is somewhat simpler than before, and I think supports everything we need. Comments? I'm happy to implement if there's a concensus.
I'm pretty happy. I think someone should put together a couple of examples from questions we've had on here first, though :) Do you actually like this better, or are you toning it down because of my previous stressing over the complexity? peace, isaac
participants (2)
-
Isaac Jones
-
Simon Marlow