[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Are DJGPP patches for autoconf welcome?
From: |
Tim Van Holder |
Subject: |
RE: Are DJGPP patches for autoconf welcome? |
Date: |
Thu, 11 Jan 2001 19:07:36 +0100 |
> | 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.