"S. Alexander Jacobson"
Perhaps it makes sense to define the mission more precisely. The document begins:
The Haskell Library Infrastructure Project is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community.
Software includes Haskell libraries and other tools writen in Haskell.
Does "software" include an IDE written in C, Python, or Java?
No.
Does it include GHC itself? Are we really trying to design a Haskell wrapper around autoconf, make, or Installshield? Why reinvent the wheel?
What do you mean? I don't think we ever claimed to be trying to implement autoconf or installshield. There are certain kinds of packages for which we think using make won't be necessary. Likewise, autoconf is overkill for certain kinds of packages. Wrapping autoconf is not the same as reinventing autoconf.
Given that this document is part of "Library Infrastructure", perhaps it makes sense to restrict the mission to:
We're going to rename the "Library Infrastructure Project" to reflect that it is for other tools written in Haskell as well. The idea that it is for libraries only keeps creeping in and I keep pusing it back, but I'm not always as firm as I should be. We really need to rename it.
The Haskell Library Infrastructure Project is an effort to provide a framework that makes it easy for Haskell developers to package *haskell libraries* for easy installation into any Haskell development environment.
I don't think we should restrict it to Haskell libraries only. I still don't see any real gain in doing so.
Following this more restricted mission, the HPS would be something that autoconf calls to interact with the local Haskell environment rather than vice-versa.
It can work both ways. The Setup.lhs script can call autoconf, which can query the package database, for instance.
Perhaps it makes sense to work through some actual real life examples. If I have a package that combines C, Perl, and Haskell? How should I distribute install it? HPS or Autoconf?
HPS can wrap autoconf in this case. It doesn't have to, though. You could implement whatever you need directly in the Setup script. peace, isaac