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

[Raja R Harinath <harinath at cs dot umn dot edu>]

Benjamin Kosnik <bkoz@redhat.com> writes:
> > 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.

I agree.  However, the two features that I suggested using
'subdir-objects' and 'include' work only with CVS automake (well, the
released automake does have 'include', but it's buggy).  

The other option is to have a Makefile.am per directory, and manually
updating the Makeflie.am whenever you add a new test -- which may not
be too bad.  Whenever you add a new test, make the following changes
to Makefile.am

  shared_tests += foo_sh
  static_tests += foo_st
  foo_sh_SOURCES = foo.cc
  foo_st_SOURCES = foo.cc
  foo_st_LDFLAGS = -static
  EXTRA_DIST += foo.tst
 
> 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 :)

Yep.  I'm not too keen to go down that path, though.  Automake already
has the setup for building binaries, and we should really be using
that.  (I've had to face a similar problem some time ago with the
'gnome-libs' testsuite setup, and just letting automake do it's thing
was so much much much simpler.)

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

OK.  I'll start testing.
 
> Please keep all the current functionality, however. This includes:
> Testing for static and shared linkage and execution, 

OK.

> testing install and build directories, 

This one is tricky.  Is this necessary for a first pass?

> putting memory limits on executables, timing compilation and links
> of executables, and timing executables.

This should be a straight forward copy of the non-build part of
'test_file()' in mkcheck.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash