On Thu, Apr 13, 2017 at 6:46 AM, Maxim Uvarov <maxim.uva...@linaro.org> wrote: > I vote for default build will not build with deprecating support. Yes all > general propose distributives will need to enable --enable-deprecated-api > to support some old software. But developers who work with git should not > work with deprecated api.
The opposite is more likely. Distros can distribute different levels of ODP and if you want the older version you just keep using the older version. So --enable-deprecated-api is really for embedded users who want (some) newer features but haven't (yet) converted older code. The key is that it is the embedded space that customizes and hyper tunes things, not the cloud, because the embedded space knows precisely the platform and configuration it's running on. By definition the cloud is more concerned with portability because the application does not control the environment--that's controlled by the operator. But no matter how you sugar-coat it, deprecation is always painful, which is why we should not do this at all, or at most only very rarely. So rarely that there is no need for a general framework for dealing with it as each deprecation will be considered on its own merits. Better to focus on structures that permit APIs to evolve over time without needing deprecation. As a practical matter, the question of deprecation is only relevant going forward from Tiger Moth / odp-cloud. There is no need to consider Monarch as "deprecatable" as it's never been part of any distro. > > Maxim. > > On 13 April 2017 at 13:57, Dmitry Eremin-Solenikov < > dmitry.ereminsoleni...@linaro.org> wrote: > >> 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. >> >> >> -- >> With best wishes >> Dmitry >>
