[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, Makefile.am 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 Makefile.am.
> >
> > 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 Makefile.am, 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
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: address@hidden
address@hidden
--------------------------------------------
- Re: More an autopackage, (continued)
- Re: More an autopackage, Ganesan Rajagopal, 2001/01/18
- Re: More an autopackage, Pavel Roskin, 2001/01/22
- Re: More an autopackage, Raja R Harinath, 2001/01/22
- Message not available
- Re: More an autopackage, Rusty Ballinger, 2001/01/22
- Re: More an autopackage, Michael Sweet, 2001/01/22
- Re: More an autopackage, Derek R. Price, 2001/01/23
- Re: More an autopackage, Ganesan Rajagopal, 2001/01/23
- Re: More an autopackage, Michael Sweet, 2001/01/23
- Re: More an autopackage, Steve Robbins, 2001/01/23
Re: More an autopackage, Michael Sweet, 2001/01/22
RE: More an autopackage,
Bernard Dautrevaux <=
- Re: More an autopackage, Geoffrey Wossum, 2001/01/22
- Re: More an autopackage, Derek R. Price, 2001/01/22
- Re: More an autopackage, Michael Sweet, 2001/01/22
- Re: More an autopackage, Geoffrey Wossum, 2001/01/22
- Re: More an autopackage, Michael Sweet, 2001/01/23
- Re: More an autopackage, Geoffrey Wossum, 2001/01/23
- Re: More an autopackage, Michael Sweet, 2001/01/23
Re: More an autopackage, Tom Tromey, 2001/01/23
Re: More an autopackage, Michael Sweet, 2001/01/23
Re: More an autopackage, David Lee, 2001/01/30