[ On Wednesday, May 2, 2001 at 13:00:46 (+0200), Stoned Elipot wrote: ]
> Subject: Desirable package's GNU autoconfiguration behaviour ?
>
> I only wanted to known what's the desirable behaviour of a package
> GNU configure script when it goes hunting around for libraries and such ? 
> 
> I mean I think it's not desirable to let a package's configure script found
> a third party library outside LOCALBASE and X11BASE, right ? Otherwise we
> would end up having as many different packages as building machines...

Yes, exactly.  In order to successfully build binary packages it is
*necessary* that all automatic detection be disabled for all libraries
outside of default supplied system libraries *unless* a dependency has
already been noted on the package which supplies the library being
searched for.

Even for X11 it's necessary to know that the target platform has X11
installed and it's necessary to use the xpkgwedge package too in order
to be sure that there are no third-party bits installed in /usr/X11R6.

> So should I restrict a package's configure hunting field according to
> what the user requested with make variables like PKG_USE_WONDERFUL_FEATURE
> (or throught a separate package like the py-* or p5-*) and
> from there introduce appropriate dependencies ?

It's often necessary to read the `configure.in' definitions for a given
package in order to try to discover what it might look for.
Unfortunately a great deal of Autoconf internals knowledge is needed to
do this "right" (or with any degree of accuracy and completeness).

Note that this issue goes far beyond just shared libraries, etc.  Some
configure scripts are even "smart" enough to look for things like the
most capable version of Awk and if it finds 'mawk' and then expects to
use it at runtime on the target system, but there's no dependency listed
on the `mawk' package, there's a good chance that the package will fail
to run correctly on the target system.  But it might work if `mawk'
happens to be installed (and maybe even because it was manually installed
on the target system)!  Testing the correctness of packages and

Of course blindly making a package depend on everything that its
configure script might happen to look for is not usualy the right thing
to do either.  The package maintainer must decide which dependencies are
necessary and which are superfluous.  Indeed creating several variant
packages which each have different optional dependencies is sometimes
useful, though if the package itself is listed as a dependent for some
other package then this can quickly get way out of hand and extremely
un-manageable unless great care is taken to define a base package that
includes all of the functionality that any other package might need.

I've mentioned this issue to the members of the autoconf mailing list,
and I think some of them have understood the problem, but unfortunately
adding any generic feature to Autoconf itself that will assist greatly
in controlling its behaviour in this manner goes somewhat against one of
the primary design goals of Autoconf and would therefore require a great
deal of time and effort.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>