Re: Merging some dwarf stuff to trunk?

[Roland McGrath <roland at redhat dot com>]

I certainly agree it would be good to get dwarflint into a release soon.
There's even an argument to be made that dwarfcmp is a useful tool,
imperfect as it still is.  But since it's a new tool, perhaps having
limited use is not worse than not having it at all.

What's certainly nowhere near ready is having the C++ headers installed so
that anything outside the elfutils build itself could use the C++ API/ABI.
But that alone doesn't mean we can't have that code in the build.

The C++ code may not be robust enough to have tools using it be called
"production ready".  We haven't concentrated on its error handling paths
and so forth.  But I'm not at all sure off hand that they are really bad.

The biggest concern I have about including any of the C++ code in the build
at all is just the portability problem of the C++ code itself.  We haven't
yet worried about trying to build the C++ code with any compilers but the
most current ones.  I'm not sure how we'll address that stuff in the
future.  But worrying about it before all the code was much more finished
and production-ready just seemed like a harmful distraction to me.

The dwarflint code relies only on a tiny subset of the C++ code.
But teasing that apart and having some of the new stuff on one
branch and some on another just seems like more distraction.
Perhaps it's not so bad in practice.

An obvious possible tactic for the portability concern is to conditionalize
building all the C++ stuff with a --disable-c++ configure option or suchlike.
Then people doing things like building new elfutils on RHEL5 would just use
that, and be as happy as they are now (and not have dwarflint to use).

I guess my feeling is still that it would be better to just try to get all
the C++ stuff closer to production quality ASAP and worry about the
portability questions only then.  But that's not a firm view at all.


Thanks,
Roland