Hi, Peter,
Peter Simons
Isaac Jones writes:
Yes, the packages will be left to the distributors. However, I think that the library infrastructure should be able to provide some metadata and tools for assisting packagers [1].
I just realize we really _are_ approaching the problem from different ends! :-)
Indeed! I've been thinking this all along :-)
I doubt there is such a thing as a common build infrastructure on which everybody could agree. Just look at the reality today: We have BSD Make, GNU Make, Jam, Boost.Jam, Odin, Cook, Automake and only god knows what else -- all being actively used for all kinds of projects. Even within the Haskell community, not everybody is using the fptools, even though it clearly can build pretty much everything.
This is the beauty of a layered tools approach like the one I describe. The "build" infrastructure can be any that the library author likes. We'll provide a nice default one, but the layer on top of that structure, like Debian and Distutils, will provide a standard interface.
[...] I'm rather convinced that duplicating any one system will leave us with 1) the flaws of that system and 2) the flaws that Haskell adds to the system by not being a perfect fit.
Uh, I was referring to Boost's model of running the source repository and their success with it -- not to their build infrastructure.
There are several systems which run source repositories that we can learn from, including Debian, FreeBSD, CPAN, Boost, etc. You've done a good job convincing me that there's a lot of work to be done in both on the distribution end and on the "building" end. If we work closely together, we can probably meet in the middle with a successful system. Do you mind helping to convert the build system for the libraries you put together once the "building" side is ready? Some points: We need to isolate overlap between distribution and "distutils" (from now on, when I say Library Infrastructure, I mean "make system" + "distutils" + "distribution"[1]). - Meta information that the libraries should provide (you probably don't have to or want to worry about this yet) will be important to methods of download / depends / install - If not a standard make system, at least a standard method for invoking the make system ala distutils and Debian. You probably don't want to worry about this yet either, but keep it in mind. Here are some suggestions on how you might proceed usefully and give us some time to come up with a plan for a build system - collect the libraries that are already included with various compilers and see what the differences are both in what libraries are included and behaviors of the libraries - find orphaned libraries (ala Numeric Quest) and try to find the authors to give them licenses. - some documentation for standards lightly based on the libraries currently included w/ compilers. These will probably want to include some reference to various licenses. Part of this task will be to help new library authors realize that they should include _some_ license with their stuff, and help them decide what license best fulfills their goals (my personal preference is GPL for applications, LGPL for libraries, and I have no trouble w/ BSD-style.) Does anyone know of a good, unbiased reference re: licenses? - a list of libraries that need better documentation, (which I'll be glad to help write) - develop the requirements / use cases or whatever for a distribution system that you plan to fulfill ala Boost. peace, isaac [1] Things that need names: Library Infrastructure includes: * Building (like the fptools make system, maybe we could call it fpmake or fpmakefiles) * Intermediate Layer (like Distutils, we'll hold off on naming it until it has more form) * Distribution (like "the hump" (OCaml) or CPAN (perl)) * A standard subset of all the libraries in the distribution, like whats currently included w/ the compilers (hslibs is taken, right?) Also, I have an idea for a mascot (see section 3.5: Mascot): http://www.haskell.org/hawiki/LibraryInfrastructure :)