Re: V3 PATCH: Use -rpath, not --rpath, when testing

[Benjamin Kosnik <bkoz at redhat dot com>]

> Preferably, the whole testsuite infrastructure should've used the
> automake 'make check' support.  'mkcheck' or a similar script would
> just have had to deal with one binary, and that too only running and
> timing the binary, and the rest could've used the libtool, dependency,
> and the (very small) test harness setup of automake.
> 
> Here's a possible outline for a testsuite/Makefile.am if you are
> willing to use CVS automake:

Not especially willing to use CVS automake. I've not been able to get it 
to work with libstdc++-v3's Makefile's, but I haven't tried it in at 
least 2-3 weeks. Besides, we just finally got the libstdc++-v3 
configure/make bits working with the last stable releases of the 
autotools, which simplifies things for everybody.

If a new stable version of automake were to be released, however, then we 
could use it......

I presume you've been following the rest of this thread about libtoolizing 
the mkcheck script?

If you beat Alexandre to this, I'm sure he won't mind terribly :)

>   AUTOMAKE_OPTIONS = subdir-objects
> 
>   TEST_ENV = time_binary
> 
>   check_PROGRAMS = $(test_names)
>   TESTS = $(test_names)
> 
>   include $(srcdir)/tests.am
> 
>   INCLUDES = -nostdinc++ -I../include -I$(srcdir)/include
> 
>   LDADD = ../src/libstdc++.la

I'm interested in a more complete patch of this, and submitting 
it to the list with a ChangeLog entry, etc. Obviously, efforts are removing 
the hacks are appreciated, and would be checked in.

Please keep all the current functionality, however. This includes:
Testing for static and shared linkage and execution, testing install 
and build directories, putting memory 
limits on executables, timing compilation and links of executables, and 
timing executables. Wheee!

-benjamin