Isaac, Bob wants to install libraries, but has only an editor and a haskell compiler/interpreter installed on his machine. Although we can't expect him to build packages created by Marcus (which require a C compiler), there is no reason he shouldn't be able to install packages created by Angela or Peter Packager (new persona!). Peter Packager runs the same OS/hardware as Joe/Bob, but has the tool chain necessary to compile/build a Haskell Package from Marcus' code. He supplies Joe with Haskell Packages that include binaries that run on Joe/Bob's machine. My claim is that the interface between Marcus and Peter should be autoconf/make. Running "./configure;make" should produce a Haskell Package which consists only of some combination of: * haskell source * binaries for Joe's os/hardware (perhaps for multiple platforms?) * documentation/metadata * datafiles Bob can then do e.g. "ghc --install /path/to/package" ("make install" should also have the same effect, but that is really up to Marcus.) Among the consequences of the above: * Cabal becomes completely declarative * It may be possible to warn the user if a package uses IO or unsafeperformIO and to tell the user exactly what binaries are being located where. * Implementation becomes substantially easier
The tools should do their job, and do it well. The compiler compiles, the build / install system installs, and you can layer a tool on top of that which tracks package databases.
From a layering perspective, I am advocating a clean interface between Peter and Bob. It is really a communication protocol that will outlast multiple generations of implementations.
It is very important to me to support tools by Marcus. His packages are actually the most difficult to manage, and the most confusing for an end user.
Agreed. That is why you need something like autoconf/make to build them and we can't expect that of Bob. The question is whether we can do better than autoconf/make in producing Haskell Packages for Bob to install.
Supporting just tools by Angela would in fact be much easier
Good. My claim is that all you need is to support Angela plus binaries.
(except perhaps for implementing things directly in the compilers, as you propose).
I don't mean to require that the compiler implement that interface but rather that you should not need anything more than a Haskell compiler/interpreter to install a package.
Fortunately, I think we can support Marcus without making Angela's job harder.
The issue is not Marcus vs. Angela. It is Marcus vs. Bob. I think you need to support Marcus<->Peter and Peter<->Bob. I don't see how you can do better than autoconf/make for the former and I don't know that there is any support in the current proposal for the later (including binaries).
If we can step back for a moment, I think you're saying that supporting Marcus isn't that important, or that it's too hard. Maybe we could break up the argument along the lines of:
1) Why we should / shouldn't support Marcus 2) What would / could a system that just supports Angela look like 3) What would a system that supports tools by both Angela and Marcus look like (this proposal is our answer to that).
I'm fairly comfortable that our system is appropriate to answer 3.
autoconf/make already support Marcus. The people who need more support are Peter and Bob.
Haskell-install deals with the execution of the wrapper script. It does so in a platform-dependent way, and can be made to understand users' compiler preferences or what-have-you.
The install should not be a script. It should be a declarative specification that allows the installer to warn the user of potentially unsafe things.
We actually have a really good idea of what the fields are, but not what the format is.
It should be Haskell. Angela is guaranteed to understand the syntax and, if you have a Haskell interpreter/compiler, verification is very easy.
Fortunately, once we've defined the interface, we can put off being precise about the fields. If you get a chance to take a look at the code, the package description looks like this right now:
data PackageDescription = PackageDescription { -- the following are required by all packages: package :: PackageIdentifier, licenese :: License, copyright :: String, maintainer :: String, stability :: String,
-- the following are required by the simple build infrastructure only: buildDepends :: [ Dependency ], allModules :: [ String ], mainModules :: [ String ], cSources :: [ FilePath ], exposedModules :: [ String ], extensions :: [ Extension ], extraLibs :: [ String ], includeDirs :: [ FilePath ], includes :: [ FilePath ], options :: [ (CompilerFlavor, [String]) ] }
Looks good, but I don't think you need all the C compilation support stuff. I do think you need a specification for resolving dependency names to actual package files so that installing a package that depends on other packages does not require multiple manual download install processes given a complete archive (CHAN?).
Is there some substantive problem with autoconf/make with respect to Haskell such that it needs to be wrapped with Setup.lhs?
No. It's a matter of providing a common interface to users and tools.
They are two distinct needs/users. Marcus delivers an autoconf/make file to Peter. Peter delivers a haskell package to Bob/Joe. -Alex- _________________________________________________________________ S. Alexander Jacobson mailto:me@alexjacobson.com tel:917-770-6565 http://alexjacobson.com