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