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

-Petri
 

> 
> Do we want to support such cases?
> 
> --
> With best wishes
> Dmitry

Reply via email to