Re: ITP: libsocket++ - Socket abstraction library for C++
On Thu, 18 Apr 2002, Junichi Uekawa wrote:
> > > Could you tell me why you are using
> > > -release @RELEASE@ instead of -version 0:0:0 ?
> > The regular libtool versioning scheme is only good for C libraries, i.e.
> > where you can exactly tell when an interface has been added, changed or
> > removed. For C++, this is difficult, since you need to take all sorts of
> > compiler characteristics into account. The basic plan is to increment
> > micro if the header file did not change, minor if it changed, but
> > recompiling the app would still work, and major if recompiling wouldn't
> > help either.
> I think you are not explaining to me clearly your reasoning.
> Are you saying that with every change every single package that
> depends on this shared library must be recompiled ?
With every change to a header file, yes. C++ libraries are only seldom
binary compatible across revisions. libsocket++ only has a single public
header file, and most of its extensibility is through a plugin
architecture, so in fact a recompile is only needed if the (abstract)
interface class changes. Since the compiler is allowed to reorder and pad
classes and structs, I cannot tell for sure what changes are incompatible,
so I give it a new interface version each time I change something.
> I have an impression that in this scheme even a change in minor
> version requires a rebuild of every binary.
Yes, that's the plan. When the autobuilder is finished, this will happen
automatically (so you can drop old versions of the library from the
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org