Mail Archives: djgpp-workers/1997/01/20/13:36:23
> Since the port of `bash' can run configure scripts almost unchanged, I
> wonder if it is appropriate to base DJGPP source distributions on the
> assumption that people who build from sources have `bash' and the
> necessary XXX-utils installed.
Well, having spent quite some time on my partly successful attempts to
port configure scripts by patching autoconf to ms_sh and gnuish XXX-utils
(back in the days before a DJGPP-port of bash was even barely possible), I
must say it's not *that* easy, after all. You would always have to account
for some of the DOSisms before the configure script actually does what it
should. So, you'ld have to distribute a modified `configure' instead of a
modified Makefile. I can't really see the great gain in this, even though
the configure script modifications might have even more of a pattern to
them than those in the Makefiles. For the record, here's the list of most
probable gotchas:
* configure scripts use 'if [ -x blabla] ; then' to scan for executable
files. This should be no problem with the current DJGPP libc version of
stat(), as it automagically searches for blabla.exe and friends as well...
* ... but sometimes, configure will look for executables or other files
using `find'. `find /bin -name "*install"' won't find
'c:/prg/djgpp/ginstall.exe', will it? This and similar approaches are
sometimes used by configure to locate programs like awk, perl or m4. And
no, they're *not* searched for in the PATH, so no usual libc magic will
work for this case.
* some configure scripts I've seen want to decide if a given path
specification is absolute or relative. In their native Un*x environment,
that's easy: if it matches the `^/' regexp, it's absolute. But in DOS,
that's a bit more complicated: `C:\', `C:/', '\' and `/' are absolute, but
neither `C:' nor `C:.' is. This can be done with a slightly more arcane
regexp, but first you have to spot this in the configure script.
IMHO, my previous approach would still be a good alternative, then: change
autoconf so that it generates special DOS-style configure scripts, with
all standard changes of the above kinds being made inside autoconf's m4
macro sets. Then distribute a changed configure.in, and perhaps an
ac_local.m4 for non-standard changes, with the sources, and that's it.
You would *not* distribute changes to either configure or Makefile in this
situation. The diffs from the original sources would be found in
configure.in and ac_local.m4, instead.
The drawback of this method that all people interested in rebuilding DJGPP
packages from source would have to acquire the ported autoconf and m4 in
addition to the already rather large set containing bash and all the
XXX-utilities. But there would also be a gain: no necessety to re-check
all the DJGPP-settings for each and every new release from the FSF.
E.g., the `configure.bat' and friends in the latest pentium gcc snapshot
won't work, just because the FSF added some autoconfigured settings that
our 'top.sed' doesn't know about.
If anyone's interested, I could try porting autoconf in the way I just
described, targetting the DJGPP versions of bash and file-/textutils. It
never worked really well with ms_sh, but the major problems I had should
not be there with DJGPP bash, so it could actually work now.
HBB
- Raw text -