On 12.04.2017 17:24, Bill Fischofer wrote: > On Wed, Apr 12, 2017 at 8:22 AM, Dmitry Eremin-Solenikov > <dmitry.ereminsoleni...@linaro.org> wrote: >> 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. > > This is really no different than supporting multiple levels of, say, > the GCC compiler. Or any other package. At some point the old releases > are no longer supported, but for some time you can have multiple > levels available at the same time and you just use the one that you > need.
We might want to consult maintainers. But from my previous experience, supporting several 'levels' is a significant headache, that most of maintainers would like to stand away from. Moreover, even if several versions are provided by distro, app developers still would like to have 'migration' path. Consider the way deprecated API are implemented e.g. in Gtk, Qt or other app frameworks. -- With best wishes Dmitry
