[ On Sunday, January 25, 2004 at 00:28:32 (+0100), Martin Weber wrote: ]
> Subject: Re: Determining the "maximum length of command line argument"
>
> Only thing remaining is how to get a list of all the symbols the thing
> should check for from our (NetBSD's) source tree ? Just to make sure
> every freaking symbol (function, typdef, structs, defines etc.) which
> someone might be interested are there :-) (maybe with tunable depth
> for ppl who think it's too big - no idea what size it would end up with).

It's relatively easy for any package to extend autoconf and many do.

So, one can only really pre-test the features which have default tests
in the standard Autoconf distribution.  Knowing that it's relatively
easy (for somone who's used autoconf before or is willing to learn about
using it at the time) to simply examine the autoconf sources and then
write a sample "confiure.ac" file that makes use of every test autoconf
can do which it would make sense to do only once on any given system.

Note though that pgksrc must simultaneously support several autoconf
releases and so care must be taken to have a unique version-identified
config.site file installed for each autoconf release, which probably
means having one of these "autoconf-site" packages for each supported
autoconf release.

Care must also be taken that the cached values don't depend on the
compiler being used either (though maybe mk/compile.mk could compensate
somewhat).

> We wouldn't want anyone to write that thing by hand, nor maintain it.

Well the packages that do the initial tests for each release of autoconf
must be written once (and then maintained).  ;-)

> Other systems with source available might use the same path to get a
> full support list for their own OS, while for those for which you do
> not have the source the NetBSD source offerings of symbols is the
> defining template; everything else offered additionally would require
> extra run-time at configure stage I assume, but that would be okay,
> wouldn't it ?

Note the information cached in the config.site file is OS (and perhaps
to some extent compiler) specific.  It can only be (safely) shared
between machines running identical OS releases (and compilers).  Note
also that in the way I'm proposing it be done the values for this cache
would be created once by actually running the tests on the target
machine.

You could make a binary package of this "autoconf-site" package I'm
proposing and then install it on other systems, though the savings may
be negligible unless you have a several similar but really slow machines
running the same OS and you build relatively few (autoconf-using)
pacakges but you build them on different machines.  Personally I'd be
building all my packages on the fastest of those machine and then
installing the binary packages on the other machines.

-- 
						Greg A. Woods

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