Re: [testsuite, build] Convert boehm-gc testsuite to DejaGnu (PR boehm-gc/11412)

[Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>]

Hello Ralf,

> * Rainer Orth wrote on Wed, Jan 05, 2011 at 07:06:56PM CET:
>> I've long maintained that it would be very helpful to convert the
>> boehm-gc testsuite to DejaGnu:
>> 
>> * It enables multilib testing, giving better test coverage.
>
> I don't understand.  Why should the current tests not be run in multilib
> setting?  Does toplevel not enter $target/$MULTIDIR/boehm-gc for check?

while make check in a non-default multilib directory works (well, sort
of: it doesn't look for the right libgcc_s.so.1), the check-TESTS
target, which ultimately does this testing, isn't multilib-aware.  Seems
like an automake problem to me (unless there is some flag to change
that; haven't looked).

>> * I set DEJATOOL = boehm-gc in testsuite/Makefile.am.  The default is
>>   $PACKAGE, which is gc, but it seemed more intuitive to see boehm-gc in
>>   mail-report.log, matching the toplevel directory.
>> 
>>   As usual, the site.exp target needs to be overridden to pass the
>>   configure-determined THREADLIBS and EXTRA_TEST_LIBS down to the
>>   testsuite.  This is quite messy; it would be far better if automake
>>   provided some facility for that.
>
> Can you open an Automake bug (send mail to bug-automake) with the
> features a better support from Automake should have?  Thanks.
> I'm still very much a DejaGNU newbie.

Sure, will do.

>> * The primary complication of the boehm-gc testsuite is the
>>   staticroottest testcase, which depends on a shared library.
>>   Currently, libtool is used to build that and I think that's the right
>>   decision rather than duplicating all of libtool's knowledge in
>>   DejaGnu.
>> 
>>   Unfortunately, DejaGnu knows nothing about libtool yet, and I'm still
>>   struggling with the right way to integrate it.  For the moment (though
>>   I fear that wrong, over-complicated) I've chosen to add two additional
>>   keywords (ltassemble and ltlink) to match assemble and link, but for
>>   .la, .lo files instead.  I'm open for suggestions for better ways to
>>   handle this, though.
>
> I'd be happy to try to help if there are libtool questions, but AFAICS
> the issue is mostly how to teach dejagnu how to use it?

I've now thought a bit more about that: the relevant DejaGnu procedures
only have the input filename available to them, so cannot distinguish
between compiling an input file into a regular or a libtool object.  So
I will need the ltassemble (compile .c etc. into .lo) type to go with
assemble (.c -> .o).  On the other hand, for --mode=link, I can see if
the input file is a .lo or a .o and select the output filename
accordingly, so my former ltlink can go.

>> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
>> +++ b/boehm-gc/testsuite/boehm-gc.lib/lib.exp	Sat Jan 01 23:52:04 2011 +0100
>
>> +    # FIXME: Explain.  Turn into parameter?
>> +    set shopt "-version-info 1:2:0 -no-undefined -rpath /nowhere -shared-libgcc"
>
> You need to prefix -shared-libgcc with -Wc, to get it past libtool.
> When creating shared libraries, libtool drops most flags that it does
> not know about (and that it could do the wrong thing with if passed),
> so with -Wc, you're telling it that you know what you're doing.
> (And -shared-libgcc actually might not work correctly in all cases,
> which is what I mean with "it does not know about a flag").

Fixed, thanks.

>> +    set shopt "$shopt $gc_lib_conv"
>
>> +    # Remove $bname.*o and .libs/$bname.*o.
>> +    # FIXME: Might use libtool --mode=clean $bname.lo, but is this right in
>
> Missing 'rm -f' after --mode=clean.

Right, fixed.

>> +    # cross-compilation scenarios?
>
> Why should it not be?

This may be just me not fully understanding the possible scenarios here:
while a basic cross should work, what about a canadian cross (build !=
host != target)?  The rm would have to be run on the host, but with
libtool would run on the build machine.  I have no idea if boehm-gc (or
any other of the libtool libraries in GCC) work properly in such cases,
though: the most I've tried so far is a basic cross to speed up
reghunting for slow targets where possible.

Maybe Joseph can shed some light here?

>> +	# Run testcase, linking with support library.
>> +	dg-test $testcase $flags "${extra-flags} $shlib"
>> +
>> +	# Remove $shlib, .libs/$shlib.*.
>> +	# FIXME: Could the removal be done in a more general place?
>> +	# Where is the rest of the removal done?
>
> Can't you use 'libtool --mode=clean' here as well?

Sure: if it works about, it will here, too.  However, I think this would
better be handled inside ${tool}-dg-test-1 than individually in each
testsuite: that's what I meant by `more general place'.

I've just done some cleanup work on the gnat.dg testsuite that gave me
some ideas for this.

In fact, I'm mostly done with a cleaned-up version of my patch that I'm
almost happy with.  I'll just have to work around a DejaGnu issue
(cannot invoke dg-test inside a running dg-test call, which I have fixed
in dg.exp itself for testing), then I'll post the result for review.

Thanks for your feedback.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University