[Haskell-cafe] cabal-install failure

[Duncan Coutts]

On Sat, 2008-06-14 at 11:03 +0100, Claus Reinke wrote:
> > http://hackage.haskell.org/trac/hackage/ticket/227
> > 
> >        One problem is that not all build-tools correspond to haskell
> >        packages. Some do some don't. We have a hard coded list of them
> >        at the moment (which can be extended in Setup.hs files) so we
> >        could extend that with what haskell package if any the tools
> >        correspond to. Any better suggestions to make it a tad more
> >        generic?
> 
> That list seems to be in Distribution/Simple/Program.hs, in case 
> anyone else is looking for it. Encoded information includes: 
> dependency name, program name (if different from dependency),

Right, we have the common name of the program. We don't actually track
the actual name as it happens to be on any particular system except in
so far as we try to find the full path to the program when we configure
it.

The main point of the Program abstraction is about configuring and
running programs. As it happens some programs are provided by some
haskell packages (but not all, eg ld, ar, etc).

> option to get version info and code to extract it (with one apparently
> very special case being hsc2hs).

And ld.exe on windows (we find it in ghc's gcc-lib bin dir).

> Btw, most of the version extraction code looks like a regular 
> expression match - wouldn't that make the specification easier
> (and turn the comments into part of the spec)?

True, in most cases finding the name of the program involves running it
with some --version flag and matching some part of the output. However
that's not always the case. Some programs do silly things like produce
the version output on stderr instead of stdout. We figured the most
general thing was just a function

FilePath -> IO (Maybe Version)

which is what we've got. I'm not sure what the advantage would be to
make it more declarative by making it into data rather than a extraction
function.

Also, the Cabal lib cannot depend on any regular expression library
because they are not part of the bootstrapping library set.

> > If anyone has a godd suggestion I'm happy to hear it. Otherwise we can
> > just add a Maybe Dependency to the Program type to indicate that some
> > build tools have a corresponding haskell package.
> 
> I'm not sure what you're suggesting there (currently even those
> tools that can be built with Cabal do not register with Cabal), but 
> here are my suggestions:
>
> 1. Haskell tools should register with Cabal, whether built with it
>     (such as Alex, Happy, ..) or not (such as GHC, ..). That 
>     registration should include any build-relevant information
>     (versions/variants, ..).
> 
> 2. When checking a build-tools dependency, Cabal checks
>     (a) whether the tool is registered with Cabal

I'm not sure this helps. We want to know what to install when it's
missing. We can already tell if a program (not package) is available by
searching for it.

>     (b) whether the tool is registered with the system installation manager

This is hard.

>     (c) whether the tool can be found by other means (configure,
>             built-in rules, ..)
> 
> In other words, make tools look like packages (lifetime dependency
> management, not just build support), and make system packages look 
> like Cabal packages (Cabal as the interface to native managers), using 
> special treatment only if absolutely necessary. I thought those suggestions
> were clear from my earlier messages?-)

Sure, haskell executable tools built by haskell packages are really
packages.

So the problem currently is that build-tools refers to programs not
packages. One can list any known program in the build-tools field and
the list of programs is extensible in the Setup.hs script.

As they are used so far by current packages on hackage, they always
refer to haskell tools built by haskell packages (almost only used to
refer to alex, happy and c2hs) so perhaps we should just quietly
redefine the meaning on build-tools to be another kind of build-depends.
That is it specifies a haskell package.

If we have need to specify non-haskell build tools, perhaps we should do
that separately? eg "some-other-kind-of-build-tools: perl >= 5.8"

Duncan