On Thu, Apr 13, 2017 at 9:07 AM, Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia-bell-labs.com> wrote: > > >> -----Original Message----- >> From: Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org] >> Sent: Thursday, April 13, 2017 1:57 PM >> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell- >> labs.com>; lng-odp@lists.linaro.org >> 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:dmitry.ereminsoleni...@linaro.org] >> >> Sent: Wednesday, April 12, 2017 3:11 PM >> >> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell- >> >> labs.com>; lng-odp@lists.linaro.org >> >> 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:dmitry.ereminsoleni...@linaro.org] >> >>>> Sent: Wednesday, April 12, 2017 2:32 PM >> >>>> To: Petri Savolainen <petri.savolai...@linaro.org>; lng- >> >>>> o...@lists.linaro.org >> >>>> 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 > >
