On 7/28/05, ross@soi.city.ac.uk
On Thu, Jul 28, 2005 at 11:53:23AM +1000, Bernard Pope wrote:
I've been using autoconf and automake for buddha, which though ugly at times, provides a nice path to making packages for various unixy systems (generally I think because this is the standard GNU way of doing things).
However, I haven't been able to migrate this over to cabal. One thing that is not clear in my mind is where cabal ends and autotools begin. There seems to be some overlap. Personally, I would love to throw away all the autotools stuff, but I'm not sure if I can easily replicate everything in cabal alone.
Is it a goal of cabal to be able to avoid autotools?
It seems to be. The Visual Haskell Studio.NET project uses _just_ the Cabal package description to build projects. So, if your Cabal project requires autotools then it won't work in that environment. In general, it seems like at least the GHC and Hugs teams want to support Windows users that don't have MinGW/MSYS or Cygwin (which means that they don't have autotools).
But if it's just Haskell, finding all the Haskell tools and using those to build executables and libraries, Cabal should do that by itself. There's currently no way to specify constraints on versions of the tools, though.
I agree that not all of the information belongs in the package description file. For example, if I only have one module that requires undecidable instances, I don't want to have Extensions: UndecidableInstances in my project file, because then everything gets built with overlapping instances turned on. Instead, I would {#- LANGUAGE UndecidableInstances -#} in one source file (assuming that it is fixed to work with GHC). Potentially, we could build a tool that can generate a list of dependencies that a project has, like this: Required-Extensions: OverlappingInstances, MultiParamTypeClasses, CPP Required-Tools: Happy, Alex, HC, GCC But, this wouldn't tell you which versions of the tools that you needed (or in the case of HC, which compiler/interpreter and which version). But, if we had a mapping like this: Hugs-1.2.3: OverlappingInstances, MultiParamTypeClasses, .... GHC-6.2.2: CPP, OverlappingInstances, MultiParamTypeClasses, .... GHC-6.4.1: GADT, CPP, OverlappingInstances, MultiParamTypeClasses, .... Then, new automatic tool could say: You cannot build this package because it requires language extension(s) that are unsupported by your installed Haskell implementation(s): Hugs-1.2.3 does not support CPP, GADT GHC-6.2.2 does not support GADT and You cannot build this package because it requires the following tool(s): Happy: (needed for src/Some/Module/Grammar.ly, ...) Alex: (needed for src/Some/Module/Lexer.x, ...) HSC2C: (needed for ...) For determining which version of a tool is required, a package author could also annotate their package description like this: Supported-Configuration: GHC >= 6.4, Happy >= 1.13, Alex >= 2.0 Supported-Configuration: Hugs >= 1.2.3, Happy >= 1.14, Alex >= 2.0.1 Tested-Configuration: GHC-6.4.1, Happy-1.13, Alex-2.0, base-1.0, HUnit-1.1, OpenGL-2.0 Tested-Configuration: GHC-6.4, Happy-1.14, Alex-2.0.1, base-1.0, HUnit-1.1, OpenGL-2.0 Tested-Configuration: Hugs-1.2.3, Happy-1.14, Alex-2.0.1, base-1.0, HUnit-1.1, OpenGL-2.0 Where, "Supported-Configuration" means "It is supposed to work with JUST these tools, plus that packages in Build-Depends" and "Tested-Configuration" means "I assert that it does in fact work with exactly these versions of these tools and packages." The new, nonexistant tool mentioned above could help automate the generation of Supported-Configuration and Tested-Configuration entries. Also, it would be a valuable tool for processing bug reports. Would this be enough information for Gentoo/Debian/RPM? - Brian