Re: [Stlport-devel] Versioninig policy

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On Tuesday 23 January 2007 11:17, Petr Ovtchenkov wrote:
> On Tuesday 23 January 2007 12:39, Ulrich Eckhardt wrote:
> > > Uli, you suggestions are unpractical and unmaintainable. You see:
> > > 1. changes in template not lead to symbol changes in libstlport, but
> > > may require rebuild application that use STLport. This is illustration
> > > for no sense of C libs naming customs for libs with massive template
> > > usage in C++;
> >
> > There are two cases to consider here:
> > 1. You need to rebuild your application because otherwise it won't run.
> > 2. Your application doesn't run due to a bug in STLport and you need to
> > rebuild it for the changes in inline code to take effect.
> >
> > The case 1 is what I'm most concerned about, this must not happen. IOW,
> > if I replace a 5.1.0 with a 5.1.1 all existing and working applications
> > must still work without rebuilding.
> >
> > I'm not concerned about case 2 where you need to rebuild an application
> > in order to get changes in STLport's inline code to take effect. This is
> > in fact the usual disadvantage of static linking or inline code. There =
is
> > nothing we can do about it. Also, because the application didn't work
> > before, we don't break anything, and breaking existing, working
> > applications is IMHO the only thing that must never happen.
>
> Uli, you arguments beyond my example: changes within template
> implementation code may not influence on libstlport, but may require
> rebuild app.

Petr, we have a communication problem with the term 'require rebuild'. As I=
=20
said, there are two cases, and one might make a rebuild _desirable_ while t=
he=20
other makes it _mandatory_. If you say 'require' it means that something is=
=20
mandatory or that you absolutely must do something. Desirable is much weake=
r,=20
it means that you probably want to do something but that it still is=20
optional.

Applications can run without having the changed inline code[1] compiled int=
o=20
them. Applications can not run if you remove symbols from libraries.=20
Therefore, changes to inline code do not require a rebuild of the=20
applications.

> Static linkage or dynamic---insignificant.=20

That was just a parallel between inline (template) code and statically link=
ed=20
libraries. In both cases, you can't exchange the code that runs in an=20
application by exchanging the library. In other words, inline code can neve=
r=20
be linked dynamically - it wouldn't be inline then.

If you look at it from that side, you have two STLport libraries, one dynam=
ic=20
part and one static part (the inline code). It could be useful to look at=20
those parts separately.

> > > 2. changes in code may lead to changes in exposed names for one
> > > compiler, but not change exposed names for other. This is specific of
> > > portable/multiplatform code;
> >
> > Well, we have a pretty good overview of what is exported and what isn't
> > exported, because win32 requires that you explicitly specify the export=
s.
> > Now, if you change the interface of such an exported class in one of
> > these ways, you are not backward compatible:
> > 1. Changing the size or layout of the object by adding/removing/moving
> > member variables.
> > 2. Removing an existing non-inline function (this includes renaming a
> > function or changing its parameters, because effectively the former
> > function is removed, and changing its accessibility
> > private/protected/public). 3. Reordering, adding or deleting virtual
> > functions. This will change the layout of the vtable and thus produce
> > surprising behaviour.
> > 4. Changing a type that the interface depends on. Example: switch the
> > begin/end pointers inside std::string. Even though std::string is not
> > exported and (almost) completely inline, it is still part of the
> > interface.
> >
> > What you can do without breaking compatibility is adding new exported
> > functions (even virtual functions, provided they are at the end of the
> > class definition). For example, this would work:
> >
> >   #ifdef BUILDING_STLPORT
> >     // TODO: remove this overload on minor version change
> >     locale combine( locale const&);
> >   #endif
> >     locale combine( locale const&) const;
> >
> > In other words, you only add an overload. For people building with the
> > newer version, the broken overload (without the const) is not visible b=
ut
> > it is still exported from the library for programs built against older
> > headers.
>
> Uli, again, I don't discuss 'how to extract symbols under Win32 OE'.
>
> Again: changes in code may lead to changes in exposed names for one
> compiler, but not change exposed names for other. This is specific of
> portable/multiplatform code; on what MOST GREAT COMPILER AND OS you will
> make decision patch/minor version?

Use the lowest common denominator. If you change an exported memberfunction=
=20
from private to public it does change the exported interface and thus we mu=
st=20
not create a library with the same name. This is regardless of the fact tha=
t=20
the interface for GCC builds probably doesn't change, it does change for at=
=20
least one compiler so we change the generated library's name.

> > Again, my main goal in library naming is that if you have a library
> > "fooX" and a newer version which is also called "fooX" that you can
> > replace the older one with the newer one without breaking things. If you
> > fix errors with such an upgrade that's cool, but even if some errors
> > remain because they are inline in the application's code that at least
> > doesn't break things that weren't broken already.
>
> Not practical: we can't guarantee this. (=3D=3D cost of such guarantee is=
 too
> high for us).
>
> > I hope you agree with me in that goal - everything
> > else is just convention and can be solved in multiple ways.
>
> No. I don't agree due to practice of code maintenance. I see that it work
> for C code (no changes in headers -> interface not changed -> increment
> only patchlevel) but not so for C++.

So, just to get you right, you would happily break existing applications by=
=20
reusing the same library name for different libraries? So what do you want =
to=20
achieve with a) the naming of the generated libraries and b) the changes in=
=20
version number? Maybe we should get this question cleared first.

Also, we need to differentiate between naming a library and version numberi=
ng.=20
Currently, the major and minor version affect the library name. I basically=
=20
don't care when we increment the version number, only indirectly via the=20
library name. If we separated those, I would not care about the version at=
=20
all and could live with any scheme.

Uli

[1] It's not template code per se, but rather inline code. Of course, most=
=20
template code is inline, apart from a few specialisations.

***************************************************************************=
***********
           Visit our website at <http://www.satorlaser.de/>
***************************************************************************=
***********
Diese E-Mail einschlie=DFlich s=E4mtlicher Anh=E4nge ist nur f=FCr den Adre=
ssaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benach=
richtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf=
=E4nger sein sollten. Die E-Mail ist in diesem Fall zu l=F6schen und darf w=
eder gelesen, weitergeleitet, ver=F6ffentlicht oder anderweitig benutzt wer=
den.
E-Mails k=F6nnen durch Dritte gelesen werden und Viren sowie nichtautorisie=
rte =C4nderungen enthalten. Sator Laser GmbH ist f=FCr diese Folgen nicht v=
erantwortlich.

***************************************************************************=
***********