> There is one effect I don't understand well in fact: that of
> AC_PATH_PROG. You now let Autoconf accept PERL=a:relative/to/perl
> where before it required PERL=a:/absolute/to/perl. Why is it so?
One reason is to avoid the second case in AC_PATH_PROG which
searches the path by setting IFS=":
>> There is one effect I don't understand well in fact: that of
>> AC_PATH_PROG. You now let Autoconf accept PERL=a:relative/to/perl
>> where before it required PERL=a:/absolute/to/perl. Why is it so?
>
> Hm, I miss a point here: I don't quite understand how it relates with
> AC_PATH_PROG since
> It make sense to me. What are the conditions to see a \ instead of a
> /?
DOS and Windows, once you get past command.com, accept both
slashes and backslashes. So filenames like 'c:/djgpp/gnu/autoconf-2.13'
are just as valid as 'c:\djgpp\gnu\autoconf-2.13'. Which is why
AC_PATH_PROG should n
> AC_PATH_PROG should now use the pattern '?:[/\\]' in the generated
Err, make that:
?:[/\\]*
Hello all,
Instead of offering a new revision of my previous patches on DOS-style
absolute paths and trying to get everything right, perhaps it would better to
just offer suggestions on how to treat DOS-style absolute paths as absolute
and leave the fixes to the Autoconf experts.
DOS style pat
Also, one more item. In AC_OUTPUT_FILES, there is a sed command that should be
reversed
to keep filenames with colons in them (like c:/windows) from being affected. Would
there be any adverse affects to the output if the colon replacement were done first?
# Don't redirect the output to AC_F
> > [/\\]* | [A-Za-z]:[/\\]* )
> >
> My understanding was that Mark says there are characters in between Z
> and a which he wants to match.
>
Right. DOS can in very rare cases have drive letters outside of [A-Za-z]. So
[A-Za-z] will work 99.99% of the time under DOS and is fine with me
(certa
Seeing as how Akim wants DJGPP to pass the testsuite, I figure it would be a
good idea report my initial results using DJGPP and Autoconf from CVS.
After setting some environment variables (CC, etc.) and correcting a DJGPP
specific bug in Bash 2.04, the test went well with one minor and one maj
> | After setting some environment variables (CC, etc.) and correcting a DJGPP
> | specific bug in Bash 2.04, the test went well with one minor and one major
> | exception.
>
> Could you give more details on these steps? What can be done to have
> it right without tuning by hand?
What I set i
> other similiar environment . My preference would be to test for programs
> using 'prog_to_find${ac_exeext}'. Then somehow figure out when ${ac_exeext}
> needs to be set without resorting to compiling a program.
or at least allow it be set in config.site until a test can be divined.
>
> | TEST_FINDS_EXE=Y
>
> Wow, are you telling us we no longer need to dive into `test $ac_x'
> and things like this?
It's a solution designed so we don't have to modify configure scripts, but
it's a hack. And it's a DJGPP-only solution, so it doesn't help EMX or any
other similiar environme
> OK, so we must start working on this.
A unified solution is certainly desirable. But perhaps we should find out how
urgent a solution to this problem is before you decide to take on this
problem for the next release. DJGPP's Bash has a solution (TEST_FINDS_EXE as
mentioned), Cygwin (I've bee
> IIUC, everything is fine, isn't it?
Relative fine anyway. Any other folks can hack their shell port to let 'test -
f prog' return true for 'test -f prog.exe' (assuming test is builtin in to
the shell they port).
> Puke puke puke! Bloody colons in file names :( I'm surprised that
> the `autoc
> + ../autoupdate -m .. -
> c:/djgpp/tmp/au16317/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open
> [c:/djgpp/tmp/au16317/m4.m4]: No such file or directory (ENOENT)
> c:/djgpp/tmp/au16317/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open
After playing with generated temporary files, it seems like a pr
> I don't get it at all. Why would you have such problems, and I
> don't???
The problem went away after the latest cvs update. I still get one failure,
but I see nothing as of yet that would classify it as DOS-specific.
=
./debug-98.sh: Testing autoupdate
=
> I don't get it at all. Why would you have such problems, and I
> don't???
>
> Can you send one of these input.m4 files? Thanks!
>
The first error messages from debug-98.sh are this:
../autoupdate -d -v -m $top_srcdir -
> So my guess is that you don't run GNU sed. I don't know too well what
> to do wrt this issue.
Every DOS utility I have is GNU, including sed.
> Have autoupdate use Perl?
Sorry, I don't understand the question.
> > So my guess is that you don't run GNU sed. I don't know too well what
> > to do wrt this issue.
>
> Every DOS utility I have is GNU, including sed.
Ahh, I found the problem, but I don't as yet have a solution:
bash-2.04$ echo "one too three four" | sed "s|\btoo\b|two"
one too three four
b
[To: line drastically trimmed]
The below is all true. I can only add the Cygwin uses a leading '//'
specially (as Posix allows) to encode drivenames for their Unix emulation.
For example, 'c:/windows' can and will be encoded as '//c/windows'. So
preserving the first double-slash would a good t
> > I'd like to volunteer to handle anything DOS/DJGPP-related if
> > possible.
>
> Thanks!
Same here.
> I'd like to advise you that it would be fair not to support non-UNIX path
> separators on the build system.
Naturally, I'll have to disagree. I don't see why Autoconf should care which
pat
20 matches
Mail list logo
