Re: DOS-style paths

[Mark E.]

> 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=":". This is a big problem when PATH 
contains drive letters.

Mark

Re: DOS-style paths

[Mark E.]

>> 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 this macro considers the absolute/relative thing
> only when checking the envvar that should point to the tool (e.g.,
> PERL=/usr/bin/perl).
> 

After looking at what Autoconf actually generates, instead of the raw 
source which is a challenge to understand, perhaps you're right and the 
absolute case should be '/* | ?:[/\\]*'. In the generated configure script, I 
see that regular relative paths are ignored, so then DOS-style ones 
should be ignored too.

Mark

Re: DOS-style paths

[Mark E.]

> 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 now use the pattern '?:[/\\]' in the generated 
configure script to keep out DOS-specific relative paths.

Re: DOS-style paths

[Mark E.]

> AC_PATH_PROG should now use the pattern '?:[/\\]' in the generated 

Err, make that:
?:[/\\]*

DOS paths v2

[Mark E.]

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 paths can have drive letters and they can have slashes or 
backslashes. I use the term "DOS-style" to refer to DOS, Windows, and OS/2 
because they all use this style.  So the typical pattern that detects 
absolute paths should be changed from:
/*)

to

[/\\*] | [A-z]:[/\\*]

This covers:
/bin
\bin
c:/bin
c:\bin

The range [A-z] is used and not ? as in my patches because it is enough to 
cover the usual drive letters [A-Za-z] and certain unusual cases with DOS 
network drives. Plus it's a little clearer that DOS style drive letters are 
being matched.

DOS style relative paths are another matter. These take the form:
x:foo/bar
or of course x:foo\bar. These should be turned into absolute paths because 
it's possible the cwd of the drive could change while Autoconf is running. To 
do this, you need the cooperation of shell that knows each drive has it's own 
cwd:
cd x:foo/bar
absolute_path=$PWD/file

Mark

Re: DOS paths v2

[Mark E.]

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_FILE directly: use `mv' so that updating
  # is atomic, and doesn't need trapping.
  ac_file_inputs=`echo "$ac_file_in" |
  sed -e "s%^%$ac_given_srcdir/%;s%:% $ac_given_srcdir/%g"`

Re: DOS paths v2

[Mark E.]

> > [/\\]* | [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 
(certainly better than nothing). [A-z] covers the rare cases, and '?' is a 
covers a little too much. Whatever consensus is arrived at is fine with me.

Mark

DJGPP testsuite results

[Mark E.]

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 major 
exception.

The test for AC_PATH_XTRA in macros.m4 did fail, but it better since DJGPP 
doesn't use X Windows. Either the test should be fixed somehow or this 
expected failure should be mentioned in the docs.

But there was a failure in tools.m4 that I couldn't figure out the cause of. 
The test is this one:

# 1. Check that `acconfig.h' is still honored.
AT_DATA(configure.in,
[[AC_INIT
AC_CONFIG_HEADERS(config.h)
AC_DEFINE(this, "whatever you want.")
]])


The traceback looks like this (excuse the odd line wrapping):
sh-2.04$ sh ./debug-95.sh -v -x

=
./debug-95.sh: Testing autoheader
=

cat > acconfig.h <<'EOF'
+ cat

# 1. Check that `acconfig.h' is still honored.

cat > configure.in <<'EOF'
+ cat

$at_traceoff
+ set +vx
./tools.m4:97: testing...
../autoheader -m .. -&6
  exit $at_status
fi
+ test 1 '!=' 0
+ test -n 1
+ cat stderr
c:/djgpp/bin/cat.exe: stderr: No such file or directory (ENOENT)
+ exit 1
sh-2.04$

Re: DJGPP testsuite results

[Mark E.]

> | 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 is:
PATH_SEPARATOR=:
TEST_FINDS_EXE=Y
CC=gcc
LD=ld

The first two are neccessary to so DJGPP's Bash can deal with the Unix-isms 
(':' is path separator, executables don't have an extension). Some linking 
tests assume 'cc' is the C compiler probably because they don't check for the 
C compiler first, so CC gets set.

> 
> | The test for AC_PATH_XTRA in macros.m4 did fail, but it better since DJGPP 
> | doesn't use X Windows. Either the test should be fixed somehow or this 
> | expected failure should be mentioned in the docs.
> 
> Please, send the config.log from this test.
> 

Here it is:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure  2.14a, executed with
 > ./configure 

configure:616: checking how to run the C preprocessor
configure:638: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:691: result: gcc -E
configure:693: checking for X
configure:757: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:753: X11/Intrinsic.h: No such file or directory (ENOENT)
configure: failed program was:
#line 752 "configure"
#include "confdefs.h"
#include 
configure:831: gcc -o conftest.execonftest.c -lXt  >&5
c:/djgpp/bin/ld.exe: cannot find -lXt
collect2: ld returned 1 exit status
configure: failed program was:
#line 821 "configure"
#include "confdefs.h"

int
main ()
{
XtMalloc()
  ;
  return 0;
}
configure:901: result: no

Cache variables:
| ac_cv_have_x=have_x=no
| ac_cv_prog_CPP='gcc -E'
| ac_cv_prog_LN_S='cp -p'

confdefs.h:
| 
| #define X_DISPLAY_MISSING 1

Re: DJGPP testsuite results

[Mark E.]

> 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.

Re: DJGPP testsuite results

[Mark E.]

> 
> | 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 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.

> | > | The test for AC_PATH_XTRA in macros.m4 did fail, but it better since DJGPP 
> | > | doesn't use X Windows. Either the test should be fixed somehow or this 
> | > | expected failure should be mentioned in the docs.
> | > 
> | > Please, send the config.log from this test.
> | > 
> | 
> | Here it is:
> 
> Hm, I still don't understand why it failed, i.e., why `configure'
> exited with 1.  Maybe `sh -x ./configure' will give more information?

Perhaps it was a Bash 2.04 bug I fixed, because I don't get an exit code of 0 
anywhere. The test itself exits with 1, but I suppose this is to be expected 
for a failure. This is result when I set CONFIG_SHELL to 'sh -x':


=
debug-66.sh: Testing AC_PATH_XTRA
=
./macros.m4:51: testing...
./macros.m4:51: testing...
./macros.m4:51: testing...
loading site script c:/djgpp/share/config.site
checking how to run the C preprocessor... gcc -E
checking for X... no
creating ./config.status
creating config.h
+ debug=false
++ echo ./config.status
++ sed -e 's,.*/,,'
+ me=config.status
+ SHELL=sh -x
+ config_headers=  config.h:config.hin
+ ac_cs_usage=`config.status' instantiates files from templates according to 
the
current configuration.

Usage: ./config.status [OPTIONS] FILE...

  -h, --help   print this help, then exit
  -V, --versionprint version number, then exit
  -d, --debug  don't remove temporary files
  --recheckupdate config.status by reconfiguring in the same 
conditions
  --header=FILE[:TEMPLATE]
   instantiate the configuration header FILE

Configuration headers:
  config.h:config.hin

Report bugs to <[EMAIL PROTECTED]>.
+ ac_cs_version=./config.status generated by autoconf version 2.14a.
Configured on host pc by
  ./configure 
+ ac_given_srcdir=.
+ ac_need_defaults=:
+ test 0 '!=' 0
+ :
+ : config.h:config.hin
+ false
+ trap 'exit_status=$?; rm -rf $tmp && exit $exit_status' 0
+ trap 'exit $?' 1 2 13 15
+ : c:/djgpp/tmp
+ tmp=
+ tmp=c:/djgpp/tmp/cs7498-8953
+ umask 077
+ mkdir c:/djgpp/tmp/cs7498-8953
+ ac_dA=s%^\([  ]*\)#\([]*define[   ][  ]*\)
+ ac_dB=[   ].*$%\1#\2
+ ac_dC= 
+ ac_dD=%;t
+ ac_uA=s%^\([  ]*\)#\([]*\)undef\([][  ]*\)
+ ac_uB=$%\1#\2define\3
+ ac_uC= 
+ ac_uD=%;t
+ test x: = x:
+ continue
+ test xconfig.h:config.hin = x:
++ echo config.h:config.hin
++ sed 's%[^:]*:%%'
+ ac_file_in=config.hin
++ echo config.h:config.hin
++ sed 's%:.*%%'
+ ac_file=config.h
+ echo creating config.h
++ echo config.hin
++ sed -e 's%^%./%;s%:% ./%g'
+ ac_file_inputs=./config.hin
+ test -f ./config.hin
+ sed -e 's/[   ]*$//' ./config.hin
+ egrep '^[ ]*#[]*define' c:/djgpp/tmp/cs7498-8953/in
+ cat
+ sed -f c:/djgpp/tmp/cs7498-8953/frag c:/djgpp/tmp/cs7498-8953/in
+ rm -f c:/djgpp/tmp/cs7498-8953/in
+ mv c:/djgpp/tmp/cs7498-8953/out c:/djgpp/tmp/cs7498-8953/in
+ echo '/* config.h.  Generated automatically by configure.  */'
+ cat c:/djgpp/tmp/cs7498-8953/in
+ rm -f c:/djgpp/tmp/cs7498-8953/in
+ cmp -s config.h c:/djgpp/tmp/cs7498-8953/config.h
++ echo config.h
++ sed 's%/[^/][^/]*$%%'
+ ac_dir=config.h
+ test config.h '!=' config.h
+ rm -f config.h
+ mv c:/djgpp/tmp/cs7498-8953/config.h config.h
+ exit 0
+ exit_status=0
+ rm -rf c:/djgpp/tmp/cs7498-8953
+ exit 0
--- config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure  2.14a, executed with
 > ./configure 

configure:616: checking how to run the C preprocessor
configure:638: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:691: result: gcc -E
configure:693: checking for X
configure:757: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:753: X11/Intrinsic.h: No such file or directory (ENOENT)
configure: failed program was:
#line 752 "configure"
#include "confdefs.h"
#include 
configure:831: gcc -o conftest.execonftest.c -lXt  >&5
c:/djgpp/bin/ld.exe: cannot find -lXt
collect2: ld returned 1 exit status
configure: failed program was:
#line 821 "configure"
#include "confdefs.h"

int
main ()
{
XtMalloc()
  ;
  return 0;
}
configure:901: result: no

Cache variables:
| ac_cv_have_x=have_x=no
| ac_cv_prog_CPP='gcc -E'
| ac_cv_prog_LN_S='cp -p'

confdefs.h:
| 
| #define X_DISPLAY_MISSING 1
./macros.m4:51: testing...
--- expout  Tue Jun  6 12:03:00 2000
+++ stdout  Tue Jun  6 12:03:02 2000
@@ -62,6 +62,7 @@
 mandir='${prefix}/man'
 no_create=
 no_recursion=
+no_x=yes
 oldinclude

Re: DJGPP testsuite results

[Mark E.]

> 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 been told) has a similiar solution, and I don't know 
about EMX. 

> 
> But after all, maybe just basing our decisions on uname is enough.

I'm convinced there is a good way to do this without resorting to uname, yet 
nobody has yet to find one.

> Aah!  I just spotted the problem:
> 
> Mark> +no_x=yes
> 
> The test suite verify that we stay in the ac_ name space, but there
> are exceptions.  And the exception for `no_x' is not in the test
> suite.  I will fix this.

Ok

> [debug-96]
 Yep, I'm lost too.  We'd need help from an expert :(  Have you tried
> to run it by hand?  It is important that you do, because I know the
> debug scripts are sometimes doing illegal fds manipulations.

I ran autoheader with '-d' to preserve traces.sh.

traces.sh:
m4trace:c:/djgpp/tmp/ac7778/stdin:2: -1- AC_CONFIG_HEADERS(config.h)
m4trace:c:/djgpp/tmp/ac7778/stdin:3: -1- AC_DEFINE(this, "whatever you 
want.")

Re: DJGPP testsuite results

[Mark E.]

> 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 `autoconf --trace' test didn't fail for you!  The expected output
> is...

For some reason it works. Go figure.

> instead?  Mark, could you check that it fixes your problem?  Or maybe
> we should be more severe and use
> 

I used the first suggested change. #96 now passes. However, now on to #97. I 
haven't looked into this yet, but my guess is it's not recognizing '?:*' as 
absolute.


===
debug-97.sh: Testing autoupdate
===

cat > configure.in <<'EOF'
+ cat

# Checking `autoupdate'.
$at_traceoff
+ set +vx
./tools.m4:180: testing...
../autoupdate -m $top_srcdir - to change it
[]ifval([], [[at_status=$?
+ at_status=0
if test $at_status != 0; then
  test -n "$at_verbose" && cat stderr >&6
  exit $at_status
fi
+ test 0 '!=' 0
$at_traceoff
+ set +vx

$at_traceoff
+ set +vx

Re: DJGPP testsuite results

[Mark E.]

> + ../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 problem with 
the brackets in _au_include. If I remove them, things go much smoother. My 
bit more informed guess is there is some sort of quoting problem.

Mark

Re: DJGPP testsuite results

[Mark E.]

> 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
=
./tools.m4:180: testing...
--- -   Fri Jun  9 12:26:57 2000
+++ stdout  Fri Jun  9 12:26:56 2000
@@ -1,6 +1 @@
-AC_INIT
-dnl The doc says 27 is a valid fubar.
-fubar=27
-AC_CONFIG_FILES([Makefile])
-AC_CONFIG_COMMANDS([default],[[echo $fubar]],[[fubar=$fubar]])
-AC_OUTPUT
+[]ifval([], [[
\ No newline at end of file

Re: DJGPP testsuite results

[Mark E.]

> 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 -

Re: DJGPP testsuite results

[Mark E.]

> 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.

Re: DJGPP testsuite results

[Mark E.]

> > 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

bash-2.04$ echo "one too three four" | gsed "s|\btoo\b|two"
one two three four

sed is linked with DJGPP's regex library and gsed is linked with the GNU 
regex library.

Re: [patch] acgeneral.m4 (dirname usage)

[Mark E.]

[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 thing IMO.

> I'm guessing that you are now talking about `dirname' from Bash or
> from Sh-utils, yes?
> 
> If so, then it does pretty much the same thing, as far as I could
> see.  "//foo/bar" yields "//foo", "//foo" yields "/".
> 
> > How about backslash handling?
> 
> The ported `dirname' handles backslashes exactly as slashes.
> 

Re: GNATS needs some work (autoconf/59)

[Mark E.]

> > 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 
path separator is used as long as Autoconf can figure it out.

> On the other hand, support for non-UNIX path separators on the host would
> be a feature that very few people need. It falls outside the area of
> "generic" macros that Autoconf contains.

I don't think I'd call the roughly 85% of people that use operating systems 
with a non-Unix path separator "very few".

Mark