Compile is an automated program compilation tool. You've seen those before: it is similar to BSD ports or the well-known equivalent Portage from Gentoo Linux (emerge). Sometimes we refer 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.
Usage: Compile <program> [<version>]
- -h, --help - Shows this help.
- -v, --version - Show program version.
- -V, --verbose - Enable verbose mode.
- -n, --app-name <entry> - Override application name.
- -e, --version-number <entry> - Override version number.
- -x, --cross-compile <entry> - Cross-compile to another architecture.
- -c, --configure-options <entry> - Options to be passed explicitly to ./configure.
- -k, --keep - Keep files is program directory already exists.
- -b, --batch - Batch mode: avoid asking questions.
- -B, --no-build - Do not build, just fetch the sources.
- -I, --no-install - Do not actually install the program.
- -W, --no-web - Do not check remote site for recipes, and bypass fetching of archives.
- -C, --no-configure - Do not run ./configure.
The rationale behind Compile
In the Linux world of 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 (
--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.
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.
Overview of Compile
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. These are the currently available execution models:
configure, which covers configure-based files;
makefile, which covers configure-less make/make-install projects;
xmkmf, which covers apps based on the X imake tools;
perl, which covers Perl modules (based on Makefile.PL);
python, which covers Python apps based on Python Distutils;
manifest, for recipes which just copy files over.
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.3.1.tar.gz file_size=4716197 file_md5=9b9722ff5ce3935ae40919b60d77d96c recipe_type=configure
Four lines, no more than that.
- 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 maintenance 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. -- Hisham Muhammad, Dec. 7th, 2003
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
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
And so on. There are quite a few interesting declarations, such as
configure_options in the
configure execution model and
make_variables in the
makefile model (also supported in
configure). Our page on writing recipes covers this information in detail.
Unfortunately, a non-negligible 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. :-)
How to use Compile
- Main article: Compiling From Source
Useflags and Compile
Set your use flags by editing /System/Settings/UseFlags.conf. The format of this file is
+flag1 -flag2 +flag3 program1 program2
Lines beginning with # are treated as comments and ignored. A list of programs may be given after the flag to have the enabling/disabling of the flag apply only to those programs.
For testing recipes and one-time compiles, you can use the USE environment variable. In this case, flag specifications are space-separated and any list of programs is separated using @ symbols.
USE="+foo -bar@A_Program" Freshen -i foo bar baz
See available use flags for a list of flags.
Developer Note: Default use flags are set in /System/Settings/GenericFlags.conf. End-users should not normally edit this file.