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:

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


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. Also implementation may 
be more efficient when deprecated code is removed.

-Petri

Reply via email to