Compile

From GoboLinux Knowledge Base

Home Concepts The GoboLinux way Filesystem hierarchy Installing GoboLinux Rootless Managing software Packages Compiling from source Writing recipes Configuring The boot process Hardware Other topics Howtos Reference

Compile is an automated program compilation tool. You've seen those before: it's a bit like to the BSD ports, or the well-known Linux 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.

Contents 1 Tool reference 2 The rationale behind Compile 3 Overview of Compile 4 How to use Compile 5 Useflags and Compile

[edit] Tool reference

Usage: Compile <program> [<version>]

Options:

• -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.

[edit] The rationale behind Compile

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.

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.

[edit] 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:

• compileprogram, 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.1.3.tar.bz2
is_compileprogram=yes

Two 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 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. -- 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

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). Our page on writing recipes covers this information in detail.

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. :-)

[edit] How to use Compile

Main article: Compiling from source

[edit] 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.