Re: Are DJGPP patches for autoconf welcome?

[Akim Demaille]

[Don't know if C-g stopped the sending of this message early enough.
If two copies, I apologize.]

Please use this address to report _bugs_, use address@hidden

| 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.

| 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.

| - 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.

| 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.

| 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.

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.

| Unix (':' and '-f', respectively), relying on a site file to override
| them on DJGPP.