RE: Are DJGPP patches for autoconf welcome?

[Tim Van Holder]

> | I'm in the process of updating my patched files to 2.49b. What I would
> | like to know is whether patches for DJGPP support would be welcomed.
> Yes, but fast if not already too late.  Small patches.
That's OK - I basically wanted to know whether integrating DJGPP support
was acceptable; whether it gets into 2.50 or 3.0 doesn't really matter
that much (DJGPP will have its own packages released anyway).

> | So far, there are only two relatively major changes:
> | - a new macro: AC_PATHSEP
> |   This substitutes @PATH_SEPARATOR@ witht the path separator used on
> |   the build system (as found in $ac_pathsep; see below)
> |   This is mainly for use in makefiles and shell scripts (in fact, my
> |   patched automake 1.4a relies on it to get its TeX-related rules right).
> Good idea.
Maybe some AC_TARGET_PATHSEP could be useful too (using CANONICAL_TARGET);
this would help get a hardcoded PATH-like variable right when
cross-compiling.

> | - AC_PATH_PROG(s) don't return a full path if configure run under DJGPP.
> |   This is because we want the produced files to be portable across DOS
> |   based systems, and to keep DOS paths out of autoconf variables as much
> |   as possible (as the colon used in a drivespec often causes trouble for
> |   autoconf, which uses the colon for its own purposes).
> Dunno.  Can't you fix the uses of `:'.  That's how we did currently.
No, the idea was that DJGPP source packages usually come preconfigured (so
the user can just type 'make' and be done with it. AC_PATH_PROG stores a
full path however, making this difficult (as PC's don't have a standardized
tree structure). So when configuring on a DJGPP system, AC_PATH_PROG will
simply return the program name without a path to work around this.
As for colons causing trouble, I have pretty much worked around that (where
needed I transform paths like 'c:/foo' to '/dev/c/foo' (an alternative
supported from DJGPP 2.03 onwards) before feeding them to autoconf routines
that look for colons (mostly the routines in config.status).

> | I've also added a _AC_DJGPP macro to the _AC_EXEEXT mechanism, but this
> | should be transparent to the user. A number of new variables were also
> I think the current CVS Autoconf makes this useless.
Right - it gets it right without these macros. I've already removed it.

> | introduced (ac_pathsep, ac_test_f), but they're set to the defaults for
> I don't like ac_test_f, and my understanding was that it is no longer
> needed.  Promote upgrading DJGPP.
True, DJGPP's bash can be forced to find executables with -f. But I consider
this a broken approach. -f is supposed to test for file existence, not
for the existence of a file that can be executed by the shell when the
given name is entered. -x is more appropriate for that. I don't hold
with breaking normal behaviour of the shell in order to be able to run a
script; it is the script that makes bad assumptions about the environment
it's run in, an as such it is the script that should be altered/adapted.
Alternatively, a test could be added looking for $foo.exe (as is done in
Perl's configure and in libtool, I think), but this would not find scripts
(.pl, .sh). On the whole, allowing a site file to determine what shell test
is used to find a file does not seem to bad.

> The problem is that care must be taken, and it's too late now, 2.50
> must be _out_.  We will see for 2.51 though.
I've been running configure scripts built with my patched autoconf on a
DJGPP system on a RedHat Linux system without any problems. I've been VERY
careful to either rely on a site file (where possible) to override the
default behaviour; there where this is impossible, a shell-based test
surrounds the DJGPP-specific commands.