On 12.04.2017 15:21, Bill Fischofer wrote: > On Wed, Apr 12, 2017 at 7:11 AM, Dmitry Eremin-Solenikov > <dmitry.ereminsoleni...@linaro.org> wrote: >> 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. >> >> 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.
Or for application developers. > 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. Yep. That is the deployed ODP release. It is optimized for speed, it is optimized for that exact platform, etc. I'm more thinking about app developers. > > 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. I'm thinking about SuSe, Canonical, RedHat or anybody else shipping ODP to enable application development on that platform. They would surely want to enable deprecated API (because otherwise old applications developed on that platform can stop building). But I'd expect that it is possible for the application developer to build an application checking that he does not use deprecated API anymore. -- With best wishes Dmitry
