This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC] make check-abi
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Wed, 21 Aug 2002 17:32:47 -0500 (CDT)
- Subject: Re: [RFC] make check-abi
- Organization: Networks and Infrastructure Lab (IL02/2240), Motorola Labs
- References: <20020821133520.A7819@disaster.basement.lan>
>> > From Loren's comments, it looks
>> > like 3.2.0 baselines will be necessary for every unique target that
>> > attempts to do abi checking. If that's the case, might as well do
>> > object size checking by default anyway.
> config/abi it is.
Yes, upon further consideration (I posted a while ago that I had an
idea to avoid the file multiplication), I'd now agree that it is
better to have a baseline for a platform triple. People that care
about a stable C++ library ABI on a platform may submit the 3.2
baseline. It should be hand-checked verses other known platforms at
submission time (as you requested the details from me; I now see I
should have just blasted you 3.2_symbols-2.txt without comment; but I
will just check it in once the framework is in place ;-).
The problem with algorithmically producing the baseline based on a
template (what I had in mind when I wrote that it should be possible
to avoid per-platform files), is that the baseline is no longer just a
direct copy of a produced file. That violates baselining 101: Never
put a human in the process when it may be avoided; we make too many
errors. ;-)
More importantly, I mistakeningly thought that we could key off, e.g.,
_GLIBCPP_USE_WCHAR_T, sizeof(this), typeof(that) and the like to
determine some parameters for expanding the baseline from a template.
However, it is possible that someone could change that setting and the
ABI checker should detect it. Thus, we still would have needed a
per-platform set of template expansion keys.
>> > 3) should system() be used instead of automake-direct-quoting insanity?
>> That's my vote. There are going to be problems eventually either way
>> (requiring GNU binutils), so whether we make the call from compiled code
>> or from scripts makes no difference.
> Ok. Well, this would take care of the other Makefile issues, namely make
> check-abi being unconditional at the moment. Then the
> testsuite/Makefile.am dependiencies could get removed.
> Building abi_check.cc always isn't a big deal to me. Sound ok?
Sounds good to me for reasons cited by Phil and the fact that it
should always build.