On 12.04.2017 14:50, Savolainen, Petri (Nokia - FI/Espoo) wrote: > > >> -----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).
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? -- With best wishes Dmitry
