Hisham Muhammad, December 7th, 2003.
Note: I had a very nice talk with Nathan last night on IRC, and I figured some things I said about the philosophy of Compile could be interesting for others to read too, so I saved the log. However, since we all know IRC logs are a pain to read, I'll try to do an adaptation here, so here we go:
More than once I referred jokingly to Compile as "the poor-man's portage". Not because it is not as feature-rich (though that is indeed true), but because it is much more minimalistic by design.
In the Linux world we live today, we are surrounded by tons of distribution formats for the same programs: .tgz's, .deb's, .rpm's... and even variants of the same format (SuSE rpm's, RedHat rpm's, Mandrake rpm's...). A program may have all of these formats available, but, especially for less fundamental programs, there is usually just a subset, leading the user to the one distribution format that is guaranteed to exist: the original .tar.gz file containing the sources.
Most of the time, this .tar.gz file can be simply unpacked, and then three magic commands, "configure, make, make install", will do the trick. Dependencies are checked by configure and the program is linked to the correct libraries present on your system, with no incompatibilities. So, if a .tar.gz is decently put together, and follows a few GNU conventions, there is no reason why it couldn't work in any Linux distributions. Therefore, ideally, no distribution formats would be needed at all, and we could live only with the .tar.gz files.
Many projects are trying to "universalize" the distribution formats in one way or another: AutoPackage, LSB, and many others. A problem I see in most of them is that they usually end up "adding layers" of project-specific things, each in its own way, tainting the (let's call it) "agnosticity" of the original .tar.gz.
Projects like GNU Autoconf and GNU Libtool on the other hand make it easy to fit a program into the most diverse environments, without requiring the system to be "this" or "that" way in order to have the package work. Supporting a few Autoconf features (--prefix, --sysconfdir...), a program is as GoboLinux-friendly as we need it to be. No need to have our own package format to store or manage sources, or to store "our versions" of each project's sources. As Nate properly said, "you can go to the project's website, download the application and install... and not look for specific packages or have to use only "your distro's" site".
While support for Autoconf and other GNU projects is improving, leading them to more and more to become de-facto standards in the free software world, we know today's reality is not as nice. So, in the meantime, we have Compile and the Recipes tree.
Compile was designed based on this vision. The Recipes are not a detailed file in the vein of ebuilds, rpm spec files and similar. Ideally, they are not to be understood as an imperative script that, well, scripts how a program is built, but rather as a declarative file that describes what the compilation process is like.
Compile is based on the fact that there a few standard ways that sources are distributed, and that there are lots of minor variations that can be declaratively specified. Each of these ways is an "execution model", and support for them is implemented separately. There are three main execution models: 'compileprogram' (which covers configure-based files), 'makefile' (which covers configure-less make/make-install projects) and 'xmkmf' (which covers apps based on the X imake tools). There is an additional execution mode, 'meta', which provides meta-packaging support (merging many packages into one).
An ideal Recipe looks like this:
url=$httpSourceforge/gphoto/libgphoto2-2.1.3.tar.bz2 is_compileprogram=yes
Two lines, no more than that. And I plan to make 'compileprogram' the default method, so that would go down to one line. Before starting this whole Compile project, I knew that the maintenance effort for the Recipes tree would be the hardest part of it (actually, that mainenance cost is what kept me from starting it for so long). So the top priority was to keep the maintenance effort for keeping the Recipes tree updated as low as possible. I think you couldn't go much lower than what I achieved so far.
Once you have a basic execution method, here is where the "features creep in". Compile supports additional declarations to describe the minor variations that exist in the various build systems for the programs out there. For example, for PSUtils, Makefile is called Makefile.unix, so you'd add
makefile=Makefile.unix
Once you unpack audacity-src-1.0.0-2.tar.gz, Audacity's sources are not in audacity-src-1.0.0-2 as expected, but in audacity-src-1.0.0, so you add
dir=audacity-src-1.0.0
And so on. There are quite a few interesting declarations, such as configure_options in the 'compileprogram' execution model and 'make_variables' in the 'makefile' model (also supported in 'compileprogram'). Unfortunately, a non-neglectable number of packages also requires imperative pre- and post- build/install scripts, in order to perform very-non-standard tasks. Shell script functions are supported for those cases.
So, what the Recipes tree aims to be is a knowledge base that tells you (or, more precisely, Compile) how standard the compilation process of a program is. We hope that free software development will evolve as to turn the Recipes tree into just a bunch of URLs. :-)
Right now, Compile/Recipes is designed as a file-based system, meaning that all recipes are stored locally. Storing the recipes in the server and downloading them on-the-fly is a logical and planned future direction. The latest Compile/Recipes snapshot contains all the scripts and all the recipes we have so far. It features 150+ packages, and it is only 68k in size, so this is probably a good thing.
As a perspective, I recall Debian supports about 4000 packages, and Gentoo already features a similar number. I heard somewhere that the BSD ports collection has 8000 packages. Given that the Compile project was unveiled, IIRC, less than a month ago, I think we're progressing fairly well. Most importantly, I believe our project has the potential to scale up well too, given than maintaining our recipes is orders of magnitude less work than maintaining .deb's or spec files.
I encourage you to try out Compile and contribute us Recipes. To use Compile, unpack the latest snapshot at /Depot. The latest snapshot can be found at:
http://gobolinux.org/~lode/GoboLinux/
(and it also usually requires the latest Scripts package, which you can always find in gobolinux.org).
Compile is packaged in an ad-hoc manner because for now I want to keep the scripts and recipes in a single package... they're evolving fast. Once they stabilize a bit, the plan is to make proper /Programs/Compile and /Files/Recipes entries. The next step will be, then, moving recipes to the server.
(By now you might be thinking: all this talk is about sources... what about the binary packages? Well, binary packages are built from sources, so the most important think to focus on managing sources first, as binaries "follow" from them).
© 2002-2022 GoboLinux.org.
gobo AT gobolinux DOT org