[Haskell-cafe] 1,000 packages, so let's build a few!

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Sun Feb 1 12:10:36 EST 2009

On Sun, 2009-02-01 at 16:50 +0000, Sebastian Sylvan wrote:

> >> Isn't this missing C library dependencies, which cabal head now warns
> >> about?
> >
> > No, it's about packages using configure scripts which require MSYS on
> > Windows.
> >
> > In principle we should be able to notice this while doing the package
> > dependency planning and report that we cannot install the package
> > because it needs sh.exe.
> >
> I wonder *why* packages need sh though? Isn't cabal supposed to allow you to 
> do that kind of scripting in Haskell rather than calling into 
> platform-dependent shell scripts?

It does enable people to make portable packages, yes. It does not
prevent people from using ./configure scripts, though as a community we
do try to encourage people only to use them where it is essential.

> Are there any specific reasons why people feel the need to use sh?

If you look at existing packages that use configure scripts you'll see
some are pretty tricky, doing lots of checks in system header files for
sizes of structures, values of constants and the presence of C functions
in various header files.

Some are trivial and should be done away with. For example the ones that
just check if a C header / lib is present are unnecessary (and typically
do not work correctly). The next point release of Cabal can do these
checks automatically, eg:

        Configuring foo-1.0...
        cabal: Missing dependencies on foreign libraries:
        * Missing header file: foo.h
        * Missing C libraries: foo, bar, baz
        This problem can usually be solved by installing the system
        packages that provide these libraries (you may need the "-dev"
        versions). If the libraries are already installed but in a
        non-standard location then you can use the flags
        --extra-include-dirs= and --extra-lib-dirs= to specify where
        they are.

> If the package is unix-only for other reasons (e.g. bindings to X or 
> whatever) then it's obviously not a problem, but it appears to me that 
> there's lots of packages that should be portable in principle that won't 
> build on windows because it needs to run sh...

We need to do a survey of the existing packages that use configure
scripts and identify what they are doing exactly. What we want to do is
work out what checks they are performing and which ones could be turned
into portable checks in cabal or in Setup.hs scripts. We want to know,
if we added feature X to Cabal, then Y packages could give up their
configure scripts.

This would be an excellent task for some volunteer to take on.


More information about the Haskell-Cafe mailing list