autogen-users

[Autogen-users] Many tests failing due to value of LIBGUILE_PATH

[Eric B. <ba...@cr...>]

I was working on packaging AutoGen for Guix (www.gnu.org/software/guix)
and came across a number of failing tests with `make check` (19 of 24 in
autoopts failed).  The failure in most cases happened on line 126 of
"autoopts/test/defs", which attempts to cd to ${LIBGUILE_PATH}/../bin.
The failure occurs because the directory does not exist.

It looks like ag_macros.m4 needs to have a better method of determining
the value of LIBGUILE_PATH.  The current method takes the path of the
last -L argument in LIBGUILE_LIBS.  For me, this path points to the
libdir for libgc, which is not installed at the same --prefix as
libguile itself, so we can't go to ${libgc-prefix}/lib/../bin because
libgc doesn't install a bin directory.

Why not use LIBGUILE_PATH=`guile-config info libdir` instead?

-- 
Eric Bavier, Scientific Libraries, Cray Inc.

Re: [Autogen-users] Many tests failing due to value of LIBGUILE_PATH

[Bruce K. <bru...@gm...>]

On 10/10/13 13:50, Eric Bavier wrote:
> I was working on packaging AutoGen for Guix (www.gnu.org/software/guix)
> and came across a number of failing tests with `make check` (19 of 24 in
> autoopts failed).  The failure in most cases happened on line 126 of
> "autoopts/test/defs", which attempts to cd to ${LIBGUILE_PATH}/../bin.
> The failure occurs because the directory does not exist.
>
> It looks like ag_macros.m4 needs to have a better method of determining
> the value of LIBGUILE_PATH.  The current method takes the path of the
> last -L argument in LIBGUILE_LIBS.  For me, this path points to the
> libdir for libgc, which is not installed at the same --prefix as
> libguile itself, so we can't go to ${libgc-prefix}/lib/../bin because
> libgc doesn't install a bin directory.
>
> Why not use LIBGUILE_PATH=`guile-config info libdir` instead?

Because, cleverly, not all distributions distribute (install) guile-config.
A better question is why doesn't Guile provide a guile.m4 file that derives
all the information one might need?  They can supply it to gnulib, if they
don't want to provide it themselves.

Meanwhile, I will add --with-libguile-path that overrides the derived
LIBGUILE_PATH value.

Cheers - Bruce

Re: [Autogen-users] Many tests failing due to value of LIBGUILE_PATH

[Eric B. <ba...@cr...>]

Bruce Korb <bru...@gm...> writes:

> On 10/10/13 13:50, Eric Bavier wrote:
>> Why not use LIBGUILE_PATH=`guile-config info libdir` instead?
>
> Because, cleverly, not all distributions distribute (install)
> guile-config.

I suggested the guile-config option because I saw that guile-config was
already being used in one of the configure paths.

> A better question is why doesn't Guile provide a guile.m4 file that derives
> all the information one might need?  They can supply it to gnulib, if they
> don't want to provide it themselves.

I can forward the question to the guile developers.

> Meanwhile, I will add --with-libguile-path that overrides the derived
> LIBGUILE_PATH value.

That should work, as long as you make the intent of the option clear
enough.


Also, I was wondering, since the problem is essentially that the the
current method picks the wrong path from "-L${path1} -L${path2}",
couldn't the configure macro do a loop over all paths and look for the
one that has a bin directory containing the executables needed by
autogen?

> Cheers - Bruce

-- 
Eric Bavier, Scientific Libraries, Cray Inc.

Re: [Autogen-users] Many tests failing due to value of LIBGUILE_PATH

[Bruce K. <bru...@gm...>]

Hi Eric,

In the intervening years, I've forgotten how everything gets done.
That automation is part of how I limit what I have to remember :).
Anyway:

On Fri, Oct 11, 2013 at 7:03 AM, Eric Bavier <ba...@cr...> wrote:
> Also, I was wondering, since the problem is essentially that the the
> current method picks the wrong path from "-L${path1} -L${path2}",
> couldn't the configure macro do a loop over all paths and look for the
> one that has a bin directory containing the executables needed by
> autogen?

That would be a better solution.  Could I encourage you to code it up?
A patch is _so_ much easier to deal with.

Thank you!

Regards, Bruce

Re: [Autogen-users] Many tests failing due to value of LIBGUILE_PATH

[Bruce K. <bru...@gm...>]

On 10/10/13 13:50, Eric Bavier wrote:
> I was working on packaging AutoGen for Guix (www.gnu.org/software/guix)
> and came across a number of failing tests with `make check` (19 of 24 in
> autoopts failed).

I am now wondering how that might have happened.
The "init_tests" function should not be run with "set -e" active.
Failing to test the results:

>  f=`\cd ${LIBGUILE_PATH}/../bin && pwd`
>  PATH=${f}:${PATH}

should just lead to a spurious ":" appended to the start of $PATH.
The following should be a little bit more rigorous:

>   f=`\cd ${LIBGUILE_PATH}/../bin 1>/dev/null && pwd` || {
>     f=`command -v guile | sed 's@/[^/]*$@@'`
>     test -d "$f" || die "cannot find guile exe"
>   }
>   case ":${PATH}:" in
>   *":${f}:"* ) : ;;
>   * ) PATH=${f}:${PATH} ;;
>   esac

But "errexit" should still not be set.

For now, I've not included --with-libguile-path just because of time.
Please try the new pre-release and if you have troubles, I'll try
to get to the "with" thing.

Thanks - Bruce

http://autogen.sourceforge.net/data/autogen-5.18.2pre7.tar.xz

Re: [Autogen-users] Many tests failing due to value of LIBGUILE_PATH

[Eric B. <ba...@cr...>]

Bruce Korb <bru...@gm...> writes:

> On 10/10/13 13:50, Eric Bavier wrote:
>> I was working on packaging AutoGen for Guix (www.gnu.org/software/guix)
>> and came across a number of failing tests with `make check` (19 of 24 in
>> autoopts failed).
>
> I am now wondering how that might have happened.
> The "init_tests" function should not be run with "set -e" active.
> Failing to test the results:
>
>>  f=`\cd ${LIBGUILE_PATH}/../bin && pwd`
>>  PATH=${f}:${PATH}
>
> should just lead to a spurious ":" appended to the start of $PATH.

Actually, it looks like you are right.  Looking at the test logs some
more, the hard errors do not occur until after this.

The real problem for most of these tests seems to be the use of
"/usr/bin/tr" instead of just "tr", since tr might not be installed at
in /usr/bin.

--- a/autoopts/test/defs.in
+++ b/autoopts/test/defs.in
@@ -289,7 +289,7 @@
   test "X${Cexe}"  = "X" && Cexe="${Csrc}"
   test "X${Dnam}"  = "X" && Dnam="${testname}"
 
-  d=`echo TEST_TEST_${Dnam}_OPTS | /usr/bin/tr '[a-z]-' '[A-Z]_'`
+  d=`echo TEST_TEST_${Dnam}_OPTS | tr '[a-z]-' '[A-Z]_'`
   cc_cmd="${CC} ${CFLAGS} -D$d ${INC} -o ${Cexe} ${Csrc}.c ${LIB}"
   eval ${cc_cmd} || \
     failure cannot compile ${Csrc}.c

> The following should be a little bit more rigorous:
>
>>   f=`\cd ${LIBGUILE_PATH}/../bin 1>/dev/null && pwd` || {
>>     f=`command -v guile | sed 's@/[^/]*$@@'`
>>     test -d "$f" || die "cannot find guile exe"
>>   }
>>   case ":${PATH}:" in
>>   *":${f}:"* ) : ;;
>>   * ) PATH=${f}:${PATH} ;;
>>   esac
>
> But "errexit" should still not be set.

Which executables are actually required for the tests?  Is it just the
'guile' executable?  If that's the case, I think configure should just
declare a precious variable named GUILE.  If the builder is already
passing the --with-libguile configure flags, it wouldn't be too much
more to ask that they then set GUILE if "guile" isn't already in PATH.
The configure and tests scripts wouldn't have to worry at all about PATH
then.

>
> For now, I've not included --with-libguile-path just because of time.
> Please try the new pre-release and if you have troubles, I'll try
> to get to the "with" thing.

With the additional patch I pasted above, the prerelease works fine.
I'll try coding up the GUILE precious variable in configure, and send a
patch if that works.

-- 
Eric Bavier, Scientific Libraries, Cray Inc.

Re: [Autogen-users] Many tests failing due to value of LIBGUILE_PATH

[Bruce K. <bru...@gm...>]

On 10/14/13 10:10, Eric Bavier wrote:
> The real problem for most of these tests seems to be the use of
> "/usr/bin/tr" instead of just "tr", since tr might not be installed at
> in /usr/bin.

Yep.  I need to add:

  TR=`command -v tr`
  test -x "$TR" || die "'tr' program is missing"

and _then_ use $TR.  Thanks.

> Which executables are actually required for the tests?  Is it just the
> 'guile' executable?  If that's the case, I think configure should just
> declare a precious variable named GUILE.  If the builder is already
> passing the --with-libguile configure flags, it wouldn't be too much
> more to ask that they then set GUILE if "guile" isn't already in PATH.
> The configure and tests scripts wouldn't have to worry at all about PATH
> then.

I've been fiddling this thing for long enough now that I have no idea.
I very likely don't even invoke "guile" anymore, but I might. :)
That would make it _really_ pointless.

>> For now, I've not included --with-libguile-path just because of time.
>> Please try the new pre-release and if you have troubles, I'll try
>> to get to the "with" thing.
>
> With the additional patch I pasted above, the prerelease works fine.
> I'll try coding up the GUILE precious variable in configure, and send a
> patch if that works.

For that to be useful, you also have to find the "guile" invocation and
use the $GUILE.  I have my doubts that it is even used any more.  :(