Syntax, shall we?

Felipe Contreras al593181 at
Wed Feb 13 08:23:53 PST 2002

On Tue, Feb 12, 2002 at 11:46:32PM -0800, Jesse Tie-Ten-Quee wrote:
> Yo,
> On Sun, Feb 03, 2002 at 12:38:40PM +0000, Mark Ellis wrote:
> > I wouldn't object to a renaming of these, but i'm not convinced by 
> > these suggestions. Setup sounds more like system configuration, and 
> > install implies that is all the step should contain, whereas there 
> > might actually be _setup_ requirements.
> Well, setup here is suppose to imply whatever you need todo before the
> building stage, while install is suppose to imply the process of actualy
> installing the package;
> <package>
>     <info>
> 	<name>wget</name>
> 	<version>1.8.1</version>
>     </info>
>     <setup>
> 	<configure>
> 	    <dir>/path/to/wget-1.8.1</dir>
> 	    <option>--prefix=/usr</option>
> 	</configure>
>     <setup>
>     <build>
> 	<make>
> 	    <dir>/path/to/wget-1.8.1</dir>
> 	</make>
>     </build>
>     <install>
> 	<make>
> 	    <dir>/path/to/wget-1.8.1</dir>
> 	    <option>install</option>
> 	</make>
>     </install>
> </package>
> So, the four major tags:
>     o info
> 	Deals with metadate, it's name and version presently.  Everyone
> 	seems to agree this is a good move as it will allow us to expand
> 	in the future. (description, homepage, author, license, etc)
>     o setup
> 	Deals with setting up the package for building.  Here we run
> 	the configure script with a default prefix of /usr.
>     o build
> 	Does the actually building of the package.
>     o install
> 	Deals with the actuall install process of the package.  This is
> 	where the executables and support files get installed, along
> 	with configuration files and so forth.

I actually like this format much more than the other one, just some

* There can be a global <dir>
	With a global dir you don't have to type again and again the same
	dir, just if you need another one you'll need to specify it.

* There can be a <sources> tag
	This will be of use if you want the program to unpack and patch or
	even download the source tree. This part is very complex if you do
	not specify the commands to prepare the source tree since not every
	package is just appname-1.0.0.tar.gz but someones are a bunch of
	tarballs patches and whatnot.

Something like:


> I've just been using setup/install mostly because i don't like the idea
> of prebuild/postbuild.  This just imples the tags under there respected
> placeholders are suppose to fall into there category.
> [PS, You may be wondering where the unpacking and removing of the
> tarball is.  One reason i moved it here is that they don't actually fit
> with any of the placeholders.  the unpacking of the tarball could
> possibly fit under setup, however the removing would not fit in the
> install process.  One option would be to add another tag, such as
> cleanup or what not.. or even just throw it in install anyways.

I think you heard me ;)

IMHO it will be much better to autogenerate those commands on the fly. As I
said the hard part is the unpacking of the sources and altought I think
it's the best that whould requiere a lot of thinking and code to handle the
format for getting the sources where we want them.

Felipe Contreras
Unsubscribe: send email to listar at
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list