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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe