autoconf
[Top][All Lists]
Advanced

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

Re: /package support


From: Stefan Karrmann
Subject: Re: /package support
Date: Mon, 10 Feb 2003 22:01:11 +0100
User-agent: Mutt/1.3.27i

Paul Eggert (Fri, Dec 13, 2002 at 01:05:32AM -0800):
> > Date: Thu, 12 Dec 2002 19:49:08 +0100
> > From: Stefan Karrmann <address@hidden>
> > User-Agent: Mutt/1.3.27i
> > 
> > Does autoconf support /package (see http://cr.yp.to/slashpackage.html)?
> 
> That depend on what you mean by "support".  It doesn't prohibit
> /package, but it doesn't go out of its way to help either.

If autoconf supports /package then

./configure --slash-package=/

should search in /package (or /command) for packages like sh,
fileutils, etc. Moreover, it should install the current package into
/package/this/package/s/global/category/package-version.

> Suppose, for example, that an Autoconf-generated "configure" finds a
> package on the installer's machine at compile-time, which is not
> available on the run-time machine, and is not explicitly listed as a
> run-time dependency.  The program won't work.  Is that Autoconf's
> fault?  Should Autoconf help out on this?  As far as I know, nobody
> has really thought about these issues.  Someone who likes /package
> will have to volunteer to do the hard slogging, I'm afraid.

In /package you can simply list the packages (with version number)
that exist on the run-time machine. Then autoconf should know the 
run-time date (shared libs, commands, etc.) while it can read the
static libs, etc. on the compile-time machine.

Ralf Corsepius (Fri, Dec 13, 2002 at 10:19:49AM +0100):
> Am Don, 2002-12-12 um 19.49 schrieb Stefan Karrmann:
> > Does autoconf support /package (see http://cr.yp.to/slashpackage.html)?
> No, because package-management is not one of autoconf's task.

Thats right, but see below.

> (It neither supports rpm, deb, slack or what ever package-management
> systems people might have brought up).

Well, /package is not a only package-management system, but defines
unique global names where autoconf could find packages/libs/includes etc.
> 
> > The /package design separates packages cleanly, such that even the
> > need of a package manager is small. It would be nice if autoconf
> > supports it, since then a lot of packages come into /package.

Cheers,
-- 
Stefan Karrmann




reply via email to

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