Mail Archives: djgpp-workers/2001/01/01/01:47:37
On Fri, 29 Dec 2000, Tim Van Holder wrote:
> The test is only used where needed to adjust the behaviour of autoconf and the
> configure script it generates
Is the generated configure script supposed to run in the native DJGPP
environment, that is, on DOS or Windows system with DJGPP development kit
installed? I understand this is so, otherwise what you do is wrong: the
default prefix should not be /dev/env/DJDIR, AC_PATH_PROG should not
return the basename, etc.
> * at the start of configure to default prefix to /dev/env/DJDIR.
Why do you need this default? What is wrong with asking the user to say
"./configure --prefix=/dev/env/DJDIR"? And config.site already does that
for the user anyway.
> * in AC_PATH_PROG to only return the filename, not the path. This allows a
> configured tree to be distributed.
Perhaps it is better to add something to config.site instead. This might
also require to add some ac_* variable to the configure script, but such
a change would probably be much less intrusive and complicated than
changing AC_PATH_PROG, and also much easier for the Autoconf maintainers
to accept.
> * in config.status, I use this to detect DJGPP, and if found, I turn a leading
> drivespec x:/ in an output file into /dev/x/, so the colon will not cause trouble
> when config.status separates output file and template. A more elegant way
> of handling this could be found, but this is an easy workaround.
I believe this should already be handled in a different way (swapping the
two -e options to Sed) in current development sources of Autoconf. I was
asking the developers to take care of that for a long time, and I think I
succeeded lately. Please check with them.
> * at the end of configure, so I can run dtou on config.status
> * in autoupdate, so I can run dtou on the updated configure.in
> * in autoheader, so I can run dtou on the output file
Since you are obviously talking about producing files for a native DJGPP
build (see above), I don't see the reason for running dtou in the first
place.
> * in autoconf, so I can close the output file (exec 4>/dev/null)
Why do you need to close the output file in the DJGPP case? Isn't
that a bug? If so, it should be treated like a bug.
In sum, I think the only special thing you need to do is to force the
configure script find the config.site file. All the rest is either
optional or can be solved by other, less intrusive means.
To find config.site, all you need is to say something like
"test -f /dev/env/DJDIR/share/config.site". I believe this
is both more robust and pinpoints exactly what you want to
find out.
- Raw text -