Imported from Trac wiki; be wary of outdated information or markup mishaps.
This page is to collect ideas for the design of Cabal 2.
The .cabal file format.
The API for loading, parsing and manipulating .cabal files. This is perhaps more important than the actual .cabal file format since the format can be extended, but the API for handling them should be easier to track.
The command line interface to packages using custom build systems. This has to be used by package managers like native package build scripts and cabal-install. This needs to be clearly defined because it is the interface that allows multiple build system implementations. It is important that the interface be usable by programs not just human users. For example sdist directly calling tar is a convenience for humans but causes problems for automatic tools like cabal-install which must call tar itself. See Custom build interface.
For example having several .cabal files in a single directory, or having a subdir per-package.
For example the gtk2hs project consists of several packages, each in a subdirectory:
gtk2hs/ gtk2hs/glib gtk2hs/gtk gtk2hs/...
Then from the top level gtk2hs directory we want to be able to cabal build and build all the packages. We also want to be able to rebuild after editing any files in any of the packages. Of course we also want to be able to build specific targets like (lists of) modules or packages, eg cabal build gtk.
In the case of several .cabal files in a single directory we can assume that all of the packages are related and to be built together. In more complex cases we probably need a more explicit way of specifying where to find packages. The fallback is always to existing pre-installed packages (ie from the global or per-user package db). A "metapackage" file could be used for this purpose, to list the paths to the packages we want to build together.
It is vital however that any stuff we add to make it easier for developers to hack on multi-package projects does not end up with having to build them together in a single build tree. The package must remain the unit of distribution so different packages have to be able to be distributed as independent tarballs and built and installed separately on other machines.
Note this is not the same thing as "shipments", see #35.
One thing that might help to clarify the design is to change the way we partition the functionality into packages. Currently we have these packages:
cabal2native tools (for arch, rpm, deb, ebuild).
There are a number of criticisms of this organisation. The declarative part of Cabal is included in the same package as the 'Simple' build system. The declarative part is an important API and is relatively stable. The 'Simple' build system has no real stable API. Also, keeping them in the same package leads to confusion over whether the 'Simple' build system is the only one that can be used.
Another criticism is that the names are confusing. The 'cabal' command line program is contained in the 'cabal-install' package, not the 'Cabal' package.
So one option would be to split the Cabal package into at least two parts, one for the declarative part and one for the 'Simple' build system.
The command line interface for users would be only the cabal command, from the cabal package.
The Setup.hs command line interface would be exclusively for tools like package manager scripts, custom build systems, cabal etc.
TODO: links to relevant mailing list discussions, particularly criticisms of the existing design.
Related to above, allow layout for lists of tokens, to make the comma optional in lists of deps if they're on separate lines. Allow trailing commas?
Should document clearly what we expect from Haskell packages, e.g. if we expect to be able to link multiple versions into a single package. Means we ought to check and enforce no symbol clashes, see issue #693.