[Bug binutils/15920] <bfd.h> not suitable as a general-purpose header

[raphael.manfredi at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15920

--- Comment #6 from Raphael Manfredi <raphael.manfredi at gmail dot com> ---
On my Debian machine, "dpkg -L binutils-dev" yields the following files:

/usr/include/plugin-api.h
/usr/include/bfdlink.h
/usr/include/bfd.h
/usr/include/libiberty.h
/usr/include/ansidecl.h
/usr/include/symcat.h
/usr/include/dis-asm.h
/usr/include/demangle.h
/usr/lib/libiberty_pic.a
/usr/lib/libbfd.a
/usr/lib/libopcodes.a
/usr/lib/libiberty.a
/usr/share/doc/binutils-dev
/usr/lib/libopcodes.so
/usr/lib/libbfd.so

If there's no ABI stability, don't provide a .so, just the .a as we don't want
to dynamically link against it.

If there is no API stability, then why not define one?  The BFD "component"
(since you insist it's not a library) seems stable enough to get a
general-purpose API.  Clearly draw the line between features that are
sufficiently high-level to require an API, and those that must rather stay
confidential.

The documentation in https://sourceware.org/binutils/docs/bfd/ seems to be a
good start for a public API...

Capitalizing on the effort required to come-up with BFD in the first place is
not only a tribute to the team, it's also saving engineering cycles for other
projects because these projects have a way to access program symbols easily,
meaning easier debugging during development, better code quality.  Everybody
wins.

I understand committing a public API is a responsibility, meaning harder work
because then you have to think about backward compatibility, etc...  It's also
something that I see worth doing.  If you don't want to make everything
visible, choose a subset that's been stable for the last 10 years.  I'm sure
most of the application-level features could be made available via a stable
API.

-- 
You are receiving this mail because:
You are on the CC list for the bug.