Sender: tim AT picard DOT skynet DOT be Message-ID: <3B5EA712.A55E6738@falconsoft.be> Date: Wed, 25 Jul 2001 13:01:38 +0200 From: Tim Van Holder Organization: Anubex N.V. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en, nl-BE, nl MIME-Version: 1.0 To: Hans-Bernhard Broeker , djgpp AT delorie DOT com, pjfarley3 AT escape DOT com Subject: Re: autoconf 2.50 question -- still need to run against unix scripts? References: <3b5e44be DOT 33943055 AT news DOT escape DOT com> <9jm373$g23$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com Hans-Bernhard Broeker wrote: > > Peter J. Farley III wrote: > > In the past, running DJGPP autoconf against previously unix-only > > configure scripts was advised to permit various unixy tests > > (especially the notorious test for executables with no "EXE_EXT" > > macros used) to work cleanly. > > Actually, that was quite a while back, AFAIK. At the moment, the > recommended solution seems to be to just run the configure script > as-is, after making sure that the DJGPP version of config.site is in > scope. Most of the necessary tricks (TEST_FINDS_EXE, PATH_SEPARATOR=: > and so on) have been put into config.site, for that purpose. Yes, bash has several workarounds for such issues, but I've tried very hard to get these things supported by autoconf directly so they will no longer be needed for configure scripts. Aside from proper executable extension support (which may make it into autoconf 2.53 mainline, and is already present in the 2.50 DJGPP release), that is now the case. Note that the autoconf 2.50 config.site file is geared strictly towards DJGPP's autoconf 2.50; in order for it to help out Unix-generated or older configures, you'll need to add if test -z "$as_ln_s" || test ! "$ac_default_prefix" = "/dev/env/DJDIR"; then # This is either an old or Unix-generated configure script # so we need to enable the bash executable-finding workarounds export TEST_FINDS_EXE=y fi # And 2.13 configures probably want this too test -z "$as_ln_s" && export PATH_SEPARATOR=: at the top. The conditionals are there because I don't recommend setting either TEST_FINDS_EXE or PATH_SEPARATOR for a configure script generated with the DJGPP package of 2.50 or higher; the former neuters the executable extension mechanism, and the latter is superfluous (configures detects the pathsep at startup). > > With the advent of autoconf 2.50 and the more recent port of bash > > 2.04, is it still advisable to re-run autoconf on unix-developed > > source packages to re-create the configure script? > > No, it isn't. autoconf-2.50 is a beta release, autoconf 2.50 is NOT a beta release. > and it's incompatible > with existing packages and their configure.in's. Even on actual Unix It is (for the most part) NOT incompatible with older autoconf's. However, due to the long inactivity of autoconf development, many configure.ins currently in use relied on undocumented, unsupported internals of autoconf 2.13 to provide their own extended functionality. Many internals were rewritten for 2.50, so many configure.ins (that were broken, but accepted by 2.13) are no longer accepted by 2.50 and above. For configure.in files that do not rely on 2.13 internals, the autoupdate script that comes with 2.50 and above should smoothly update the file, so very little manual work (if any) is needed to upgrade to 2.50. > systems, most packages stop working if you run autoconf-2.50. If you It is true many Unix-based packages are experiencing problems upgrading (including, but not limited to, Gnome 2.0). But a) these are mostly due to the reasons listed above, and b) autoconf 2.13 is dead - it's obsolete and unsupported, so it is not recommended to keep on using it for production software > want to run autoconf on existing packages, use the DJGPP port of > autoconf-2.13. Only if the package explicitly requires 2.50 (you'll > notice: it should have AC_PREREQ(2.50)), you'll want to use that. Well, I'd suggest first trying autoupdate + autoconf 2.50; on the whole, autoconf 2.50 is much better at support DOS and OS/2 without requiring the shell to have special workarounds enabled. For problem files, it would probably be easier to run the DJGPP version of 2.13 (though I would prefer it if DJGPP maintainers upgraded to 2.50). If it would be useful, I could update the autoconf 2.50 package (or 2.52 if I release it) to also contain 2.13 in parallel, so you could easily have both installed (for cases when you're unable or unwilling to upgrade). -- Tim Van Holder - Anubex N.V. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This message was posted using plain text. I do not endorse any products or services that may be hyperlinked to this message.