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
archive).
Simon
--
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 debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: