Mail Archives: djgpp-workers/2001/01/01/06:55:10
> 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.
That's my point: the configure script generated should run on both
DOS/Windows and Unices. That's why the changes (/dev/env, AC_PATH_PROG)
are activated by the tst; if DJGPP isn't found, all these things behave
in the original way.
Examples:
# part of _AC_INIT_DEFAULTS
if test -d /dev/env/DJDIR -a -n "$DJGPP" -a -f "$DJGPP"; then
ac_default_prefix=/dev/env/DJDIR
else
ac_default_prefix=/usr/local
fi
# from AC_PATH_PROG
case $$1 in
[[\\/]]* | ?:[[\\/]]*)
ac_cv_path_$1="$$1" # Let the user override the test with a path.
;;
*)
AC_SHELL_PATH_WALK([$4],
[if test $ac_test_f "$ac_dir/$ac_word"; then
if test -d /dev/env/DJDIR -a -n "$DJGPP" -a -f "$DJGPP"; then
# In order for DJGPP-based packages to be distributable, we can't use
# a specific path here. This is not a perfect solution, but better
# than requiring a uniform file system structure on each PC.
ac_cv_path_$1="$ac_word"
else
ac_cv_path_$1="$ac_dir/$ac_word"
fi
break
fi])
> 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.
Laziness, I suppose. That way, I don't need to specify --prefix (like
/usr/local on Unices, $DJDIR is a pretty good guess for DJGPP) and I can
easily find config.site (without additional tests).
> > * 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.
As the change ONLY affects configures run on DJGPP, I don't see a big problem;
If you insist, I'll add a variable to force the standard behaviour, but I
don't think I'd want it to be the default. The fewer full DOS paths are used,
the better.
> > * 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.
In 2.13, it used to be that easy. But now they do:
ac_file_inputs=`IFS=:
for f in $ac_file_in; do
case $f in
-) echo $tmp/stdin ;;
[[\\/$]]*)
# Absolute (can't be DOS-style, as IFS=:)
test -f "$f" || AC_MSG_ERROR([cannot find input file: $f])
echo $f;;
*) # Relative
if test -f "$f"; then
# Build tree
echo $f
elif test -f "$ac_given_srcdir/$f"; then
# Source tree
echo $ac_given_srcdir/$f
else
# /dev/null tree
AC_MSG_ERROR([cannot find input file: $f])
fi;;
esac
done`
test -n "$ac_file_inputs" || AS_EXIT([1])
Because of the IFS=:, dos paths would be split up, causing
autoconf no to find the templates. So because of this, I
transform DOS-style paths to /dev ones internally (and since
those transformed names are rarely displayed, this should not
be too big a problem for the user.
> > * 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.
Since I'm talking about producig files that run on both DJGPP and
Unices, the dtou's are needed. For one, a CRLF configure script
will fail miserably (with very odd error messages) if fed to the
Linux version of bash2. With the dtou's, I had no problem running
a DJGPP-generated configure on Linux. Mind you, I didn't do exhaustive
testing yet; that'll have to wait until I have my new box and am
running Linux at home too.
> > * 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.
Nope, it's DOS. The file was created through exec 4>file.name, and bash
keeps the file open. Without the exec 4>/dev/null to close the file,
dtou (stock 2.03, mind you) will not complain, but the output file will
have DOS-style line endings.
> 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.
I suppose I could do this instead (and I could use the site file to
set the prefix as well). And since a site file is required for proper
djgpp functionality anyway, it's indeed sufficiently robust.
It doesn't obviate the need for most of the tests though, and since the
changes are only run when they're needed (ie on DJGPP), they're hardly
intrusive.
- Raw text -