Steve Langasek wrote:
I think that tool designed for one simple feature must be in one file.
On Fri, Aug 07, 2009 at 04:57:38PM +0400, Andrey Ponomarenko wrote:
2) icheck was intended for the same purposes as an
ABI-compliance-checker, but icheck has many drawbacks:
c) icheck contains 467 files and 61 sub-folders;
ABI-compliance-checker is a single file.
I am concerned that you think this is a feature.
-fdump-translation-unit compiler option provides only more convenient
output (syntax tree) for checking compatibility.
d) icheck searches changes in `gcc -E -x c-header header_name.h`
output, that represent a header after preprocessing - it is a very
inconveniently method because it need a lot of code for parsing header
(about 750 kb of code); ABI-compliance-checker searches differences in
the `gcc -fdump-translation-unit header_name.h` output, that represents
a syntax tree of the header files.
I'm not familiar with -fdump-translation-unit. Is there any possibility
that ABI-compliance-checker will overlook ABI changes that icheck will
ABI-compliance-checker's representation of the ABI really depends on
architecture. But it is not important. You may transfer all your header
files to another host and compare it.
Does ABI-compliance-checker's representation of the ABI behave in an
architecture-independent fashion, so that it's possible to draw conclusions
about ABIs on other architectures than the architecture on which you're
running the check?
I was completely wrong, icheck may generate compatibility report in one
e) as described in the documentation
(http://www.digipedia.pl/man/icheck.1.html) icheck need three runs to
get compatibility report - it is not easy.
You are right, ABI-compliance-checker does not allow such advantages
yet. But usually upstream library developers have all installed
versions on one host (if not, they may install it), and you may
transfer all your header files as well as your "manifest"
representation to other host and check it.
Huh? You have to have a representation of the baseline ABI to compare
against. Does ABI-compliance-checker assume that both copies of the header
will be unpacked and available locally at the same time, in order to be able
to do everything in "one run"? That would be much less useful; we don't
want to have to carry around the actual headers or objects from the
reference version of the library in order to be able to run these tests, we
would want to be able to ship a "manifest" representation of the reference
ABI in our sources to compare against.
In general icheck may be used for checking binary compatibility of C
libraries, but it has several drawbacks.