Survery of Setup.hs with Cabal-1.2
duncan.coutts at worc.ox.ac.uk
Thu Sep 27 12:05:03 EDT 2007
This is a survey of the problems in updating to Cabal-1.2. (This is independent
of the problems in updating to GHC-6.8, though of course many people will
encounter both at the same time.)
I've compiled The Setup.(l)hs scripts of all 248 packages (394 package-version
pairs) on hackage with the new Cabal-1.2 library. Of those, the Setup scripts
from 20 packages fail to compile (there are 31 package-version pairs). 4 more
compile but with warnings.
I've categorised the failures by their cause & remedy:
There are several packages which currently use custom code in the Setup.hs
script that can now be replaced entirely by using the new configurations
feature. They are doing things like picking the dependencies based on the ghc
version or the operating system. This is exactly what configurations are for.
These packages can then use the "build-type: Simple" and the trivial Setup.hs
hsql-odbc-1.7 (actually does compile but with a warning)
A similar case is using code to run an external program to discover the correct
build flags for a package. In general this still needs to use custom code but in
the common case of using the "pkg-config" program we can take advantage of the
pkg-config support in Cabal-1.2 and again get away with using the build-type:
Simple and the trivial Setup.hs script.
An API change in the "UserHook" hooks interface that affected many Setup scripts
was that the result type was changed from IO ExitCode to just IO (). Then
instead of returning codes all over the place (which were not being consistently
checked) we now use IO exceptions instead. So Setup scripts which used to return
ExitSuccess can now return () and ExitFailure n can be replaced by exitWith
YamlReference-0.1 to 0.5
There are a number of packages where the Setup script makes extensive use of the
internal API of Cabal's default build system. I'll mention each one briefly:
fenfire-0.1: needs updating to use new PreProcessor abstraction. Can drop the
local def of c2hs pre-processor as this hack is no longer required in the
minimum version of c2hs that Cabal supports (and it probably would no longer
lhs2tex-1.12: requires significant work. It makes use of the Program abstraction
and system for managing installation dirs both of which have changed significantly.
hsql-mysql-1.7, hsql-postgresql-1.7: requires significant work. can be
simplified by using the cabal api effectively and using configurations. These
both call external config programs to find the right build flags. I posted an
update to hsql-mysql-1.7 the other day as an example.
alex-2.1.0, happy-1.16: requires significant work (though already done in darcs
versions). Again these used the internal Program abstraction which changed
yi-0.2, hint-0.1: These both try to find ghc's libdir. The both could be
significantly simplified by doing things in the 'proper' way which is to use the
HookedBuildInfo stuff rather than writing little .ghc-libdir files.
xmobar-0.3.1-0.7: The Setup.hs for this package completely re-implements the
haddock command to customise the way docs are generated for executables. This is
no longer necessary in Cabal-1.2 as it provides the features required. So the
Setup.hs can be replaced with default and use build-type: Simple.
Packages for which Setup.hs compiles with a warning with Cabal-1.2:
These three packages add a feature that was missing in Cabal-1.1.6 but is now
present in Cabal-1.2. They add a --ghc-option= and --configure-option= flag to
the configure command. Cabal-1.2 implements this generically for all programs
that it knows about (and the programs it knows about can be extended by the
Setup script). So again, these can use build-type: Simple and the trivial Setup
One immediate cause of problems is Setup scripts importing
Distribution.PreProcess, Distribution.Program which have moved under
Distribution.Simple. I could add re-exports for both as I did for
Distribution.Setup however both modules have changed significantly so any Script
that actually uses these modules needs changing anyway, so theres no particular
advantage to providing a module re-export crutch.
I might make module Distribution.Simple.Utils export rawSystemVerbose again
since some scripts use it. Though all those that do have other problems as well.
So overall that's not too bad. Less than 10% of the hackage packages are
affected by the significant internal changes in Cabal-1.2. Of those, only 9
packages need significant work to update their Setup scripts and 12 others can
eliminate their custom Setup code completely using new features in Cabal-1.2.
The remaining 3 need only minor changes.
More information about the cabal-devel