This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: compile/runtime testing for __cxa_atexit
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: Paolo Carlini <pcarlini at suse dot de>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Thu, 1 Sep 2005 12:21:51 -0500
- Subject: Re: compile/runtime testing for __cxa_atexit
- References: <20050831170206.0162160b.bkoz@redhat.com><431631A5.9000803@suse.de><20050831181146.5810daa3.bkoz@redhat.com><43163E8B.5080704@suse.de>
> Longer term, maybe we can investigate whether we can unify somehow the
> different approaches that we have for named locales vs wchar_t/threads.
> Probably it's not urgent because the final effect is similar (and
> correct) - in some cases, a smaller number of tests actually run - but
> maybe the former is a tad more robust?!? I'm not sure. In particular,
> I'm not sure which one is more friendly to Mark's ideas about testing
> without the build dir.
I do prefer the named locale approach, as you can guess since I just
copied it largely unchanged for the __cxa_atexit work. However, I think
that we'll have to have wchar_t and thread macros in libstdc++, so it's
ok to do that kind of dejagnu style as well.
I do think we should
resist adding macros to c++config.h just for use in the testsuite,
which is another reason the more autoconfy, compile/run look at the
results kind of test like dg-require-namedlocale are cool.
(Now that I think about it, I wonder if the memory limit stuff can be
moved over to dejagnu instead of autoconf. Anyway. There's no big rush
to do this.)
>From what I can tell, both will work without the bulid dir.
The main advantage of the dejagnu requires style is that it doesn't
impose naming conventions like "thread" and "wchar_t" to be part of the
full path name. However, I don't consider this to be a big deal, and to
be honest, I think we need to organize a lot of the testsuite along
these lines anyway, as it matches the functionality of the standard. I
suspect this was your point?
What I really like, with both approaches, is that the "unsupported"
tests are now numbered accurately. I find that a big help! The current
results are much more accurate for systems like Solaris and AIX.
-benjamin