X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f From: Tim Van Holder Subject: Re: Which cxxfilt.exe? Which config.site? Date: Mon, 25 Feb 2002 14:01:11 +0100 Newsgroups: comp.os.msdos.djgpp Message-ID: References: <3c74fec8 DOT 1409243 AT news DOT earthlink DOT net> User-Agent: Pan/0.11.2 (Unix) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Comment-To: "Peter J. Farley III" Lines: 59 Organization: -= Skynet Usenet Service =- NNTP-Posting-Host: 194.78.64.238 X-Trace: 1014642143 reader1.news.skynet.be 33506 194.78.64.238 X-Complaints-To: abuse AT skynet DOT be To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com In a burst of inspiration, "Peter J. Farley III" wrote this on Thu, 21 Feb 2002 15:21:23 +0100: > They are radically different, with only a couple of common entries. In > the case of the PATH variable set by the config.site from acnf250b.zip, > if PATH already contains (for example) "c:/djgpp/bin", it creates > functionally duplicate entries in the PATH, and it could make the PATH > exceed it's maximum length, causing more problems than it solves. The reason /dev/env/DJDIR/bin is prepended is to cause configure to find DJGPP exutables with that path, so that -) config.cache files are more portable across DJGPP environments -) applications that hardcode such a path at compile time will still work on systems with a different DJDIR I suppose I could do a hairier transform of PATH (replacing $DJDIR/bin with the /dev/env path if present), but I'm not sure it's worth it. > However, what I'm mainly wondering is whether those "ac_cv_func_..." > entries in the copy from acnf250b are truly needed when running > /configure scripts. They are mostly useful for packages that haven't been ported to DOSish systems yet. They'll test for fork() and use it, which results in breakages on DOSish platforms. We have a fork() function, but not a working one; using the ac_cv_* vars makes autoconf think this has already been tested for (and not found). > Perhaps Tim and Mark E. should get together on this and come up with a > consolidated version. The problem is this: autoconf and bash evolve at a different pace. Users should not need to install autoconf just to run configure scripts, so config.site is included with bash. But newer versions of autoconf may need additional/fewer entries in config.site. Since it's unreasonable to require a new bash package every time this happens, config.site is also included in the autoconf package. I'll post newer versions of config.site to djgpp-workers for review before I build an autoconf package. > Advice appreciated. I'm currently using a config.site that detects the autoconf version used to create the configures script being run, and sets variables accordingly (based on the config.site that comes with bash 2.05). This will also be included in the DJGPP package for autoconf 2.53 (when it's released). I'll try to remember to post it in this thread tonight. > # The root of the DJGPP tree serves as the default prefix. # Allow for > cases where a top-level Cygnus/Red Hat-style configure script # calls > Autoconf configure scripts in subdirectories. if test > "x$ac_default_prefix" = "x/usr/local"; then > ac_default_prefix="/dev/env/DJDIR" > fi I don't do this anymore; and I'm still in doubt over whether I should have DJGPP's autoconf default to DJDIR as prefix. Using --prefix seems cleaner (and is the 'normal' way of pulling in a system-wide config.site, instead of using $CONFIG_SITE).