>>>>> "Mark" == Mark E <[EMAIL PROTECTED]> writes:
>> | TEST_FINDS_EXE=Y
>>
>> Wow, are you telling us we no longer need to dive into `test $ac_x'
>> and things like this?
Mark> It's a solution designed so we don't have to modify configure
Mark> scripts, but it's a hack. And it's a DJGPP-only solution, so it
Mark> doesn't help EMX or any other similiar environment . My
Mark> preference would be to test for programs using
Mark> 'prog_to_find${ac_exeext}'. Then somehow figure out when
Mark> ${ac_exeext} needs to be set without resorting to compiling a
Mark> program.
OK, so we must start working on this. I am unable to extract a good
method to spot non-Unix environment in the thread about it. Nothing
appeared to be right.
But after all, maybe just basing our decisions on uname is enough.
Yes, this is against the philosophy of Autoconf, but it's better than
nothing. And I guess we don't have to fear portability problems with
uname, since I suppose the environments we want to check for do
support it, right?
Mark> Perhaps it was a Bash 2.04 bug I fixed, because I don't get an
Mark> exit code of 0 anywhere. The test itself exits with 1, but I
Mark> suppose this is to be expected for a failure. This is result
Mark> when I set CONFIG_SHELL to 'sh -x':
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.
[debug-96]
Mark> Something is definitely wrong here, but it will be difficult to
Mark> find out exactly what.
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.
cat >acconfig.h <<EOF
/* Define this to whatever you want. */
#undef this
EOF
cat >configure.in <<EOF
AC_INIT
AC_CONFIG_HEADERS(config.h)
AC_DEFINE(this, "whatever you want.")
EOF
../autoheader -m .. -<configure.in
Maybe it will help to see what happens.
Akim
