[Haskell-cafe] cabal-install failure

[Duncan Coutts]

On Mon, 2008-06-16 at 13:25 +0100, Claus Reinke wrote:
> > 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).
> 
> I didn't notice this special case in Program.hs - are my sources
> just out of date, or is this special handling encoded elsewhere?

It's in the configuration code for ghc. If it's on windows then it tries
to find ld.exe relative to where ghc was found.

> >> 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.
> 
> Usually, the most general approach for this kind of problem is
> good as a default/backup, but not so good for maintenance. The
> more cases can be handled with dedicated declarative specs, the
> smaller the risk of accidental/hidden breakage (eg, moving the 
> comments into regex patterns), the more compact and understandable 
> the specs (a line per tool, with option and regex, all in one place
> would be easier to comprehend than the current free-coding style).

So we can provide a more compact helper function for the common case bu
since not all of them fit the common case we cannot change the general
interface.

> More importantly, concise declarative specs are easier to update
> and extend (could be done by users rather than Cabal maintainers,
> and preferably outside of Cabal sources).
> 
> > Also, the Cabal lib cannot depend on any regular expression library
> > because they are not part of the bootstrapping library set.
> 
> Sigh. I've heard that one before, and the ghc-pkg bulk queries are
> not as flexible as they could be because I had to use less expressive
> functions instead of regexes. Since Haskell-only regex packages
> exist, perhaps one should just be added to the bootlib set? After
> all, we bother with regexes because they are so frequently useful.

In the specific case of parsing --version strings, I'm not sure regexes
are any easier. Using words and then selecting the Nth word seems to do
pretty well.

> >> 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.
> 
> But that means either configure or a subset of special configure
> rules baked into Cabal's sources, combined with fragile Setup.hs
> extensions to that subset. IMHO, the less of configure/hardcoded
> rules/Setup.hs, the better (simpler, less breakage with Cabal 
> updates, etc.).
> 
> How about this: instead of baking rules for those tools into the
> Cabal sources, why not have a single "known-tools" package?
> On (re-)installing that package, its configure/Setup is run once,
> to register availability and build-related information for all those
> tools with Cabal (currently, that would mean a package per
> tool; later, the known-tools package itself could expose multiple
> tools, but Cabal would still need to be able to check which of 
> the "exposed-tools" have been found).
> 
> That way, the known-tools could be updated independently,
> instead of requring Cabal source hacking and releases, and
> instead of spreading special configure rules for common tools
> over all packages, they'd be located in a single package 
> (easier to maintain and improve, and improvements are shared).

Yeah this would be better. The same goes for things like pre-processors,
but their rules are harder to express.

> >>     (b) whether the tool is registered with the system installation manager
> > 
> > This is hard.
> 
> Why? Because there are more installation managers than OSs,
> or because so many program installs bypass them? Querying
> an installation manager shouldn't be any more difficult than
> querying ghc-pkg, say.

Both. There are many of them, each with their own quirks and things
installed in /usr/local.

Duncan