Ping. Review needed. Are we ready to merge? This should work fine with distros as explained two weeks ago.
-Petri > -----Original Message----- > From: Bill Fischofer [mailto:[email protected]] > Sent: Thursday, April 13, 2017 6:02 PM > To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell- > labs.com> > Cc: Dmitry Eremin-Solenikov <[email protected]>; lng- > [email protected] > Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros > > On Thu, Apr 13, 2017 at 9:07 AM, Savolainen, Petri (Nokia - FI/Espoo) > <[email protected]> wrote: > > > > > >> -----Original Message----- > >> From: Dmitry Eremin-Solenikov > [mailto:[email protected]] > >> Sent: Thursday, April 13, 2017 1:57 PM > >> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell- > >> labs.com>; [email protected] > >> Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros > >> > >> On 13.04.2017 10:33, Savolainen, Petri (Nokia - FI/Espoo) wrote: > >> > > >> > > >> >> -----Original Message----- > >> >> From: Dmitry Eremin-Solenikov > >> [mailto:[email protected]] > >> >> Sent: Wednesday, April 12, 2017 3:11 PM > >> >> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia- > bell- > >> >> labs.com>; [email protected] > >> >> Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros > >> >> > >> >> On 12.04.2017 14:50, Savolainen, Petri (Nokia - FI/Espoo) wrote: > >> >>> > >> >>> > >> >>>> -----Original Message----- > >> >>>> From: Dmitry Eremin-Solenikov > >> >> [mailto:[email protected]] > >> >>>> Sent: Wednesday, April 12, 2017 2:32 PM > >> >>>> To: Petri Savolainen <[email protected]>; lng- > >> >>>> [email protected] > >> >>>> Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros > >> >>>> > >> >>>> On 30.03.2017 16:58, Petri Savolainen wrote: > >> >>>>> Replaced ODP_DEPRECATED macro (which was based on GCC > __attribute__) > >> >>>> with > >> >>>>> compiler independent mechanism to control if deprecated API > >> >> definitions > >> >>>> are > >> >>>>> visible to the application. ODP_DEPRECATED_API can be used both > in > >> >>>> application > >> >>>>> and implementation to check if deprecated APIs are enabled. By > >> default > >> >>>> those are > >> >>>>> disabled. Implementation may optimize the normal (new API) code > >> path. > >> >>>>> > >> >>>>> ODP_DEPRECATE() macro is used to rename definitions, so that data > >> >>>> structure > >> >>>>> sizes are equal on both options. This enables implementation to > >> serve > >> >>>> both > >> >>>>> options with a single library (if it wishes to do so). > >> >>>> > >> >>>> My main question remains as it was before: is it possible for the > >> >>>> distribution to supply (unoptimized) ODP binary and headers and > then > >> >> for > >> >>>> the application to select if it builds with or without deprecated > API > >> >>>> using that binary/headers? > >> >>> > >> >>> > >> >>> Yes. This patch set keeps the same struct fields/etc for both modes > - > >> >> only the names are scrambled (with __deprecated_ prefix) when > >> deprecated > >> >> APIs are not supported (the default). > >> >> > >> >> If so. Consider I have built and installed ODP headers & binary > built > >> >> with --enable-deprecated-api. > >> > > >> > So, you have built and installed the implementation with --enable- > >> deprecated-api. This means that applications using this install, see > >> deprecated APIs. A distribution decides which way it supports ODP, with > or > >> without deprecated stuff. The default in our (odp-linux) configure is > >> without, to minimize confusion and promote the new API definitions > which > >> should be always better for application than the old ones. > >> > > >> > >> I was advocating for binary distributions and developers using packages > >> from those distributions. And for those distributions providing > _single_ > >> binary version of ODP. > > > > Obviously, a distribution would select which ODP API versions are > supported, and if those versions include deprecated APIs or not. > Deprecation is feature of API spec and thus header files. A header file > cannot be in both modes at the same time. E.g. a struct either has a field > e.g. int foo or int _deprecated_foo, but not both at the same time. > > > > A single library can support both modes since struct sizes are the same > (_deprecated_foo is left with default values since application does not > read/write it). > > > > Now, if a distribution dictates that deprecated APIs are supported, an > implementation delivers headers with deprecated stuff and a library that > supports those. The same happens in the opposite case (headers without > deprecated stuff and an library that supports those). Depending on > implementation the library binary may be same or different. Distribution > does not care, since it needs to store headers and pairing libs for those > in any case. > > > > We do not guarantee binary compatibility over different API versions. > Application, API headers and implementation lib need to be on the same API > version - with or without deprecated stuff. > > Good summary. Having ODP part of a distro simply means that someone > has installed it in the library catalog associated with that distro > and configured it however they wished. At that point it's either part > of the default install or can be installed with apt-get, yum, etc. > > What gets installed are the include files that allow applications to > compile/link against that ODP installation, and the associated .so > files that provide the runtime support for these apps. If I look on my > Ubuntu 16.10 system I see /usr/include/clang and under that are > several different release options (3.6, 3.6.3, 3.8, and 3.8.1 in my > case). Similarly there is a /usr/lib/clang/ with the individual > releases under it. ODP is no different. I'd expect there to be > /usr/include/odp/<release> and /usr/lib/odp/<release> directories > present. At that point it becomes a business decision, as to which > releases / configurations a given distro offers. > > So if an application is built to run on ODP release X then it needs > the libraries associated with release X to be available to it. If the > distro also offers release Y and Z that's fine, but the app still will > continue to run just fine as long as release X is still available. How > long that is is an LTS consideration because at some point release X > will no longer be supported and the application will have to move to a > currently supported release. When it does that it needs to do two > things: > > 1. Ensure that it's not using any APIs that are no longer present in > the new release > 2. Recompile against the new release > > Given that it's had years to prepare for step 1, I don't think it's > unreasonable to assume that we have no need to support deprecated > APIs, so distros aren't going to bother with having deprecated APIs > being part of newer releases. If we wanted to continue their support > it would be simpler to just continue the LTS for release X. > > Again, deprecation is a rare event and is mainly a documentation / > communication / planning matter, not something that needs a lot of > infrastructure support. > > > > > -Petri > > > >
