On Fri, Feb 24, 2017 at 2:30 AM, Savolainen, Petri (Nokia - FI/Espoo) <[email protected]> wrote: > From: Bill Fischofer [mailto:[email protected]] > Sent: Thursday, February 23, 2017 7:28 PM > To: Brian Brooks <[email protected]> > Cc: Petri Savolainen <[email protected]>; LNG ODP Mailman List > <[email protected]> > Subject: Re: [lng-odp] [API-NEXT PATCH 2/4] api: deprecated: add > ODP_DEPRECATED configure option > > I have to agree with Brian here. Cluttering up the API spec files with > #ifdefs seems ugly and unnecessary, and tying this into autotools at a spec > level also seems awkward. > > The idea was to mark certain fields as deprecated in one release and then > remove them in a follow-on release. We can make the actual removal subject to > SC vote if the concern is that things might get removed too soon, as there's > no harm in carrying them with the deprecated markings until such time as > there is agreement they really can be removed. Allowing individual developers > to "reach back" to resurrect them just means that they have to > be kept around forever as they're never really removed. > > > > NO HTML mails please > -------------------- > > First, this design pattern is copied from our version.h.in API file:
OK > /** > * ODP API generation version > */ > #define ODP_VERSION_API_GENERATION @ODP_VERSION_API_GENERATION@ > > > xxx.h.in files are not part API, but the generated xxx.h files are. After > autotools have done it's work, there's include/odp/api/spec/deprecated.h file > which has this content: > > /** > * Deprecated API definitions > * > * Some API definitions may be deprecated by this or a previous API version. > * This macro controls if those are enabled (and visible to the application) > * or disabled. > * > * * 0: Deprecated API definitions are disabled > * * 1: Deprecated API definitions are enabled > */ > #define ODP_DEPRECATED 0 > > If an implementation does not use autotools, it may generate the same > deprecated.h file with the same content anyway it likes (or hard code the > file into the repo). I disagree strongly. Such API header files should contain pure C code, and not anything that requires the file to be run through autoconf or for people to maintain their own set of API header files. Things like @ODP_VERSION_API_GENERATION@ can be defined to a real concrete value. Things like ODP_DEPRECATED can also be defined to a real value .. conditional on the compiler identification macro. > > Second, this patch does not take any position how long a deprecated API > remains there. The patch enables application build *with* or *without* > deprecated APIs, so that it's easy to verify if deprecated APIs are (still) > used in application or not. For example, I missed couple of those in IPSEC > example app porting previously, but now with this option those were caught. I am confused again. Use of the compiler's support for "deprecated" will cause a warning to be emitted if application code is still written to use said deprecated APIs. Are you saying this is not good enough? Or, are you trying to create a way to still support some idea of "deprecated" in the case that there is no support from the compiler? > Also implementation may be more efficient when deprecated code is removed. > > -Petri >
