X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f From: pjfarley3 AT earthlink DOT net (Peter J. Farley III) Newsgroups: comp.os.msdos.djgpp Subject: Re: Which cxxfilt.exe? Which config.site? Message-ID: <3c7a4bc4.2134726@news.earthlink.net> References: <3c74fec8 DOT 1409243 AT news DOT earthlink DOT net> X-Newsreader: Forte Free Agent 1.21/32.243 Lines: 89 Date: Mon, 25 Feb 2002 14:38:47 GMT NNTP-Posting-Host: 24.199.95.40 X-Complaints-To: abuse AT earthlink DOT net X-Trace: newsread1.prod.itd.earthlink.net 1014647927 24.199.95.40 (Mon, 25 Feb 2002 06:38:47 PST) NNTP-Posting-Date: Mon, 25 Feb 2002 06:38:47 PST Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Mon, 25 Feb 2002 06:38:47 PST (newsmaster1.prod.itd.earthlink.net) To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Tim Van Holder wrote: >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. I completely understand the rationale for putting it in there. I just wanted to point out that many of us already have quite long PATH's, and if we're running autoconf, we probably already have the DJGPP PATH set. Adding another (slightly longer) copy of it *could* break things unexpectedly. And the transformation does not have to be very hairy, a simple gawk script would do it, or maybe even a sed script (I'm much more comfortable with gawk than with sed, hence my first thought is a gawk pattern match and substitution). Unconditionally prepend "/dev/env/DJDIR/bin" and conditionally delete "$DJDIR/bin" is all I think it will take to prevent (well, *mostly* prevent) unintentional failures. >> 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). That's what I thought they would be useful for. There's no harm in using them all the time, is there? I think they should be activated by default if there's no harm in it. >> 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. I know it's not GNUish, but perhaps config.site for DJGPP should be placed into a new "package" all by itself, so it could be updated independently of the development pace of either 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. That would be very helpful. Thank you. >> # 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). I agree, I use --prefix consistently myself. But this is what we are delivering to the DJGPP users, and they trust us to know what they need. I think the djgpp-workers list needs to come to agreement over this, and then set things up accordingly. If it matters, I vote with you *not* to set it by default. You could also put in comments indicating that a user *can* set this themselves, if they so wish, and pointing out the risks if they do so. Thanks for the thoughtful reply. ---------------------------------------------------- Peter J. Farley III (pjfarley3 AT nospam DOT earthlink DOT net)