[Haskell-cafe] cabal-install failure

[Claus Reinke]

> 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?
 
>> 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).

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.

>> 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).
 
>>     (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.

If a program is registered with, eg. Windows Add/Remove
Programs, I can use "reg query <key>" to find its registration
info, and if I don't know the key, I can use

reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall /s

to list all registered programs, or

reg export HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall <file>

to get all registration info dumped to a file, and look for
DisplayNames of the tools I'm interested in:

>reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall /s | 
    find "DisplayName" | find "Opera"
    DisplayName REG_SZ  Opera 9.50

>reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall /s | 
    find "DisplayName" | find "Hugs"
    DisplayName REG_SZ  WinHugs

>reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall /s | 
    find "DisplayName" | find "Haskell"
    DisplayName REG_SZ  Glasgow Haskell Compiler, version 6.4.1

Of course, the tools I'm interested in very often bypass the 
Windows installer (eg, I prefer tarballs for GHC, and GHC comes
with its own internally used set of tools, or Cygwin handles its own
tools itself, and so on) and so won't appear in that output.. 
 
Claus


>>     (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
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe