Subject: Re: Determining the "maximum length of command line argument"
To: None <tech-pkg@NetBSD.org>
From: James K. Lowden <email@example.com>
Date: 01/25/2004 15:35:33
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.