RE: Are DJGPP patches for autoconf welcome?

[Tim Van Holder]

> So I'd rather wait for 2.51, but for dumb stupid changes.
No problem. I'll see if I have any dumb stupid changes (one I can
think of is a Fortan-related test where a file called 'conftestval'
is used; this resolves to 'conftest' on 8.3 systems, causing
trouble; using conftest.val instead fixes this) and submit patches
for those).

> Tim> No, the idea was that DJGPP source packages usually come
> Tim> preconfigured (so the user can just type 'make' and be done with
> Tim> it. AC_PATH_PROG stores a full path however, making this
> Tim> difficult (as PC's don't have a standardized tree structure). 
> Of course it makes it hard!  Why don't you let the user configure
> themselves?  That you run a modified Autoconf seems logical.  That you
> preconfigure sounds wrong.
I think the idea is to require as few packages as necessary. Unlike
Unices, DOS systems don't usually have sed/awk/tr etc which are required
by configure, but not usually required by a make. DJGPP users can
usually make do with just gcc, binutils, make, fileutils and bash.

> Tim> True, DJGPP's bash can be forced to find executables with -f. But
> Tim> I consider this a broken approach. 
> Yep, but merely introducing ac_test_f doesn't sound right either.  In
> fact, it *is* on the list of things to change in Autoconf, but in a
> cleaner way, which means much later.  There is something which works
> today, that's all we need.
OK - so I won't include that in the patches I submit (though I think I'll
still use it in the DJGPP package I make; I see nothing particularly
wrong in this approach).
I suppose the only clean way to handle this would be to use 'which',
which will probably know how to DTRT for the system in question. But then
again, which'es are probably not standardized, and this adds another
dependency to autoconf.

> Tim> Alternatively, a test could be added looking for $foo.exe (as is
> Tim> done in Perl's configure and in libtool, I think), 
> Hm, not a bad idea, now that we have ac_exeext available.  Alexandre,
> Pavel, any comment?

> Tim> but this would not find scripts (.pl, .sh). 
> Well, (i) check for foo, then (ii) foo$ac_exeext?
Yes, but I tend to use actual .pl and .sh extensions for executable
Perl and shell scripts, respectively. This is usefule because a) DJGPP's
system()/spawn() functions know about common script extensions, so bash
will find these if you type their name without the extension, and b)
because I can configure my DOS shell (4DOS) to invoke perl/bash on these,
so I can run them from outside of bash.
So if you only test for foo and foo.$ac_exeext, you wouldn't find
'aclocal.pl' or 'nroff.sh'. Also, DOS has '.com' and '.bat' as standard
executable extensions, and those also would not be found. So while it is
better than just '-f foo', it's still not great (while '-x foo' would
DTRT on DOS).