www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2002/02/25/11:00:33

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: <Pine DOT SUN DOT 3 DOT 91 DOT 1020221091141 DOT 3007A-100000 AT is> <3c74fec8 DOT 1409243 AT news DOT earthlink DOT net> <pan DOT 2002 DOT 02 DOT 25 DOT 14 DOT 01 DOT 08 DOT 408884 DOT 22072 AT spamproofemail DOT com>
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 <notme AT spamproofemail DOT com> wrote:
<Snipped>
>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)

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019