[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: More an autopackage

From: Bernard Dautrevaux
Subject: RE: More an autopackage
Date: Mon, 22 Jan 2001 14:13:45 +0100

> -----Original Message-----
> From: Derek R. Price [mailto:address@hidden
> Sent: Friday, January 19, 2001 10:36 PM
> To: address@hidden
> Cc: Geoffrey Wossum; address@hidden
> Subject: Re: More an autopackage
> Tom Tromey wrote:
> > Unfortunately, I don't think it is that easy.
> >
> > First, contents can be conditional on the particular
> > configuration.  That is why you really want to deal with the
> > post-configuration package (using `make') and not
> >
> > Second, the more complex post-install scripts are generated by
> > automake itself.  For instance, take a look at the hair required to
> > install an info page.  It would be a pain for developers to have to
> > insert this code by hand (if they even know it exists).
> Good point, but the general design I pointed out should still hold.
> Only the generated Makefile would be the source for the data 
> needed for
> spec file generation rather than the, whether 
> that's passed
> in or scanned.  The pre/post install hair should be scannable from the
> Makefile as well, whether that's for a shared library or info.
> The spec file source would want room for install hooks as well, still.
> That way instructions for, say, taking a daemon down and up 
> again could
> be inserted before automake acquires a daemon target.

I think this need to depend on the configure-generated Makefile will have a
very constraining effect on the implementation language: this precludes
using ANYTHING that's not installed standard on any of the expected target
OSes... That's exactly why configure generates sh-scripts and why libtool IS
a shell script.

You can use GNU m4 or PERL in autoconf and automake, as these are
maintainer-only tools. If autopackage is a package-installer tool (i.e. a
native package front-end) the choice of implementation language is almost
restricted to "/bin/sh" or "/bin/sh" and probably "/bin/sh" :-)

Just a thought, hoping to be wrong,


Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
Tel:    +33 (0) 1 47 68 80 80
Fax:    +33 (0) 1 47 88 97 85
e-mail: address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]