On Mon, 20 Jul 2020 13:32:27 +0100
"Burakov, Anatoly" <anatoly.bura...@intel.com> wrote:

> On 18-Jul-20 3:22 AM, Stephen Hemminger wrote:
> > On Fri, 17 Jul 2020 16:21:37 +0100
> > "Burakov, Anatoly" <anatoly.bura...@intel.com> wrote:
> >   
> >> On 16-Jul-20 11:04 PM, Stephen Hemminger wrote:  
> >>> On Thu, 16 Jul 2020 14:41:41 +0100
> >>> "Burakov, Anatoly" <anatoly.bura...@intel.com> wrote:
> >>>      
> >>>> On 15-Jul-20 9:29 PM, Stephen Hemminger wrote:  
> >>>>> On Wed, 15 Jul 2020 14:28:17 +0100
> >>>>> "Burakov, Anatoly" <anatoly.bura...@intel.com> wrote:
> >>>>>         
> >>>>>>> -#define SKIP_MASTER  SKIP_INITIAL
> >>>>>>> -#define CALL_MASTER  CALL_INITIAL
> >>>>>>> +#define SKIP_MASTER _Pragma("GCC warning \"'SKIP_MASTER' is 
> >>>>>>> deprecated\"") SKIP_INITIAL
> >>>>>>> +#define CALL_MASTER _Pragma("GCC warning \"'CALL_MASTER' is 
> >>>>>>> deprecated\"") CALL_INITIAL  
> >>>>>>
> >>>>>> Presumably this is a generic header, should we introduce GCC-specific
> >>>>>> things there?  
> >>>>>
> >>>>> It works with Clang as well. Likely ICC but don't have that.
> >>>>>         
> >>>>
> >>>> What about MSVC?
> >>>>     
> >>>
> >>> _Pragma is C99 standard so MSVC know it.
> >>> MSVC should ignore any pragman it doesn't understand.
> >>>
> >>> There is a better pragma for deprecating keywords in MSVC, but GCC and 
> >>> Clang don't
> >>> understand it.
> >>>      
> >>
> >> Deprecating macros sounds like something we might want to do in the
> >> future, can't we put some macro into rte_common.h to address this? e.g.
> >> something like
> >>
> >> #ifdef MSVC
> >> #define rte_deprecated_macro _msvc_pragma_whatever()
> >> #else
> >> #define rte_deprecated_macro _Pragma("GCC warning ...")
> >> #endif
> >>
> >> and use this macro here?  
> > 
> > It gets hard to do macro in a macro,
> >   
> 
> I don't have a strong opinion on this, but IMO it's certainly better 
> than having a compiler-specific things in an API header file :)
> 

I was hoping for macro volunteer?

Something like:
#define RTE_DEPRECATED(foo) ...

Reply via email to