Mail Archives: djgpp-workers/2001/01/02/03:48:46
> Sorry, I'm not sure I understand what you are saying. Do you agree
> that setting the prefix to $DJDIR in config.site is good enough, or
> do you still think you need a special change in Autoconf?
With the suggestion you made below, I do think it would be quite
acceptable to set the prefix in config.site (I'd need to check what
happens between the setting of the prefix and the loading of the init
file, to make sure there are no side-effects of this).
> I think that, in general, it is better to solve problems in our
> config.site than in Autoconf itself. config.site is under our
> control, while Autoconf maintainers constantly change the code in a
> way that repeatedly breaks DJGPP support (see the next item for an
> example).
I agree. However, some of these changes, like the AC_PATH_PROG one,
cannot be resolved simply by setting some value in the site file.
There would still have to be a test to decide what to do.
And I would think an Autoconf maintainer would be less likely to
accidentally break a test that clearly shows its intention (ie testing
for /dev/env/DJDIR and $DJGPP), than one using some internal flag (say,
$ac_djgpp).
>> 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.
>
> I didn't want the standard behavior to be preserved, I wanted a change
> to get the behavior you suggested, but without excess dependency on
> Autoconf maintainers. If that is possible, of course.
As I mentioned, I don't immediately see a way to control this cleanly
from inside config.site.
>>> 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=:)
>
>
> It looks like saying "IFS=';'...." here will DTRT for us. Autoconf
> can do that automatically if "$COMSPEC$ComSpec" is non-empty, and the
> same solution will work for MinGW.
>
> Isn't this easier to have Autoconf define ac_path_sep variable whose
> value is either : or ;, depending on "$COMSPEC$ComSpec", and then use
> ac_path_sep in the above snippet? Then you will not need a
> DJGPP-specific test and won't need to convert drive letters to /dev/c
> format.
I already have an ac_pathsep variable (and although I currently depend
on a site file to override the default ':', I suppose I could make the
default depend on the comspec test). However, it's not a path that's
being split here, it a template spec. And using ';' here (or even worse,
CONDITIONALLY using ';'), would require changing configure.in files all
over the place. I'm not sure the autoconf maintainers are willing to
make such a major change just yet (although they might for 3.0, as they
don't plan that release to be backwards-compatible).
Example:
AC_CONFIG_HEADER(foo.h:foo.hin)
AC_CONFIG_FILES([po/Makefile.in:po/Make-in foo.spec:foospec.in)
If the configure script made from this is called with --srcdir=d:/src
(or if, as with emacs, the configure script forces srcdir to be
absolute), the list of template specs becomes:
foo.h:d:/src/foo.hin
po/Makefile.in:d:/src/po/Make-in
foo.spec:d:/src/foospec.in
It can get even worse, as a single file can depend on multiple
templates, though I have not seen (m)any configure.in's using this feature.
It's easy enough to find pathspecs in this (^.:[\\/] and :.:[\\/]).
Finding the non-pathsep colons (so IFS can be changed) would be a LOT
harder.
>> Since I'm talking about producig files that run on both DJGPP and
>> Unices, the dtou's are needed.
>
>
> Producing configure scripts and other files that will run on Unix is a
> noble goal, but I'm not sure how heavy a price should we pay for
> that. AFAIK, this is the only case where such a goal is even set.
> Info files produced by makeinfo, config.h and Makefile's produced by
> configure, scripts produced by libtool---all these have the DOS EOL
> format. Why should we go to such great lengths to make Autoconf
> different? All it takes to make the script be runnable on Unix is to
> run dtou on it by hand--hardly a problem for someone who wants to use
> a configure script.
I suppose so. Still, since all it takes is that call to dtou, this does
not seem to big of an issue. For the use in config.status, I could even
make it a value ($ac_dtou) to be set in config.site (defaulting to the
':' no-op). The uses in autoconf/autoheader/etc. would still need a
regular test.
Note that there is another valid reason to use dtou, besides Unix
compatibility of the output. In many case, makefiles and/or will use
'cmp' to compare file to decide whether some command needs to be run.
And unlike diff, cmp DOES care about EOLs. One example is autoupdate;
without the dtou, the new configure.in will never match the original one
(provided the original wasn't utod'd).
If all we need to do is run dtou once, I think it's worth preserving
compatibility.
>> For one, a CRLF configure script
>> will fail miserably (with very odd error messages) if fed to the
>> Linux version of bash2.
>
> It's not a Bash problem, it's a Linux kernel problem: it cannot grok
> the magic "#!/bin/sh" signature if it ends in \r\n. Unlike in the
> DJGPP port, on Unix the kernel interprets #!/bin/sh and invokes Bash.
Maybe, but the problems I'm referring to come when running 'sh
./configure' and the like, so the kernel doesn't have to do any
grokking. As it seems, the CR's are usually, but not always, ignored,
resulting in problems (CR's ending up in file names, error messages
get screwed up, etc.) This would seem to be a bash/sh problem, not a
kernel one. And I'd be very surprised if your average Unixy shell
handles CRLF EOLs without problems (even though the kernel may be able
to feed it to them).
> (But this is just a comment, it doesn't have much to do with the issue
> we are discussing.)
It's not entirely irrelevant, as this failure was my reason for
including the dtou's.
> Does the problem happen because you run dtou with "exec 4>" still in
> effect, or because something else? In other words, if you don't
> invoke dtou, does the problem go away?
Because of the exec 4>, bash keeps the file open. Zhen dtou needs to
remove the original (so it can rename the dtou'd file to it), this
fails, as DOS won't let you do that to an open file.
> If the problem happens only because you run dtou, then maybe running
> it in a different place (or not running it at all ;-) would solve the
> problem. Or maybe the script could "exec 4>/dev/null" on all
> platforms, without testing for DOS/DJGPP.
I'm only running the exec 4>/dev/null to make dtou work (on Unices, you
can remove/rename/etc an open file without problems), and since this is
just about the final command run in the script, using the exec on each
platform is probably unwarranted.
> I think you should really minimize the number and volume of changes
> you send to Autoconf maintainers. Each change brings questions,
> suggestions for alternative solutions, discussions, rework, more
> suggestions and discussions, etc. (And I didn't even say
> ``rejections'' yet ;-). Each such change can be later broken by some
Since the maintainers are apparently close to a release, it seems
unlikely that my changes will make it into 2.49 anyway.
And since my day job has now resumed, I won't have too much time to
spend on it now either.
Once I've run the entire testsuite (it takes soooooo long) and verified
I've not broken anything in the move to 2.49b, I'm going to work on CVS
some more (trying to get the 'as-binary-as-possible' mode working).
> changes in Autoconf. That's why I suggest to do as much as possible
> in config.site, which is under our control and whose change process is
> much simpler.
I've tried to do this as much as possible; those changes that are still
inside autoconf itself probably can't be made from config.site.
--
Tim Van Holder - Falcon Software N.V.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message was posted using plain text. I do not endorse any
products or services that may be hyperlinked to this message.
- Raw text -