> -----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. -Petri
