On Wed, Apr 12, 2017 at 7:11 AM, Dmitry Eremin-Solenikov <[email protected]> wrote: > 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. > > How do I build: > > - application that uses deprecated API? > [I assume that the answer to this question is trivial: just build as is]. > > - application that wants to be sure that it does not use deprecated API?
As a practical matter, the support of deprecated APIs is similar to the current provision for debug builds (--enable-debug and --enable-debug-print in the current ./configure script). These really are only of significance in the embedded space. In the cloud profile, applications use whatever ODP release(s) are installed on the system and the normal library-matchings are used to ensure that applications built for Release X are paired with library .so files compatible with that release. In this case, there are no deprecated APIs since applications only move to newer ODP release levels when they are ready. A cloud host system may specify the minimum ODP release level available on it, and that determines when laggards need to upgrade. So ODP will never ship a distribution that was configured with --enable-deprecated-api. The only users of this feature will be embedded applications that are customizing ODP to their own needs. > > > -- > With best wishes > Dmitry
