On Sun, 25 Jan 2004, Martin Weber <Ephaeton@gmx.net> wrote:
> On Sun, Jan 25, 2004, Julio M. Merino Vidal wrote:
> > On Sat, Jan 24, 2004, James K. Lowden wrote:
> > > 
> > > Whether or not a package uses config.cache depends on the package,
> > > on how the configure script is invoked.  
> > > 
> > > It seems to me it would make more sense for pkgsrc to write a
> > > reasonable/usr/pkg/etc/config.site when pkgsrc/pkgtools/pkg_install
> > > is installed, unless it already exists.  
> > 
> > pkgsrc could also know the maximun line length beforehand (put it in
> > all defs.*.mk files) and then set the right environment variable to
> > this value before executing a GNU configure script.
> 
> Hmm, that would require an in-pkgsrc database of all hosts as compared 
> to a per-host local installation of a run result for a specific host. I
> dunno, is the info there already ? then of course it'd be easier, just
> needed to be available. If it had to be added all by hand .. hmm ..

Correct me if I'm wrong, but I don't think we'd need any in-pkgsrc
database.  AIUI, the instant question is, "What's the maximum size of a
command line?"  That's a function of the shell, specifically
@CONFIG_SHELL@, normally /bin/sh.  Everything built with pkgsrc on a given
machine would use the same shell to process the configure scripts.  If we
used autoconf+configure when the tools are installed, we could stash its
determination in /usr/pkg/etc/config.site. 
 
The only liability I can see is that the answer could change, over time. 
It seems unlikely, however, that the any new shell would accept *shorter*
lines than its predecessor, so, at worst, configure might unnecessarily
choke, thinking the new shell is limited to command lines shorter than it
can, in fact, process.  

--jkl