Re: [Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.02.17 at 14:10, <JGross@xxxxxxxx> wrote:
> On 28/02/17 13:46, Jan Beulich wrote:
>>>>> On 28.02.17 at 13:24, <JGross@xxxxxxxx> wrote:
>>> On 28/02/17 12:11, Jan Beulich wrote:
>>>>>>> On 28.02.17 at 11:34, <JGross@xxxxxxxx> wrote:
>>>>> In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined
>>>>> on the command line of the build instruction. This conflicts with
>>>>> xen-compat.h defining it unconditionally if __XEN__ or __XEN_TOOLS__
>>>>> is set.
>>>>
>>>> Then that's what wants fixing. In fact it's questionable whether
>>>> __XEN_TOOLS__ (or even __XEN__) getting defined there is
>>>> appropriate.
>>>
>>> There are multiple libraries from the tools directory being compiled
>>> for stubdoms.
>> 
>> Each if which should get appropriate settings.
>> 
>>>>> Just use #undef in this case to avoid the resulting warning.
>>>>
>>>> I think the lack of a warning in case of a collision is worse here.
>>>> People should simply not define both the version symbol and
>>>> either of __XEN__ or __XEN_TOOLS__.
>>>
>>> Would you be okay with:
>>>
>>> #if defined(__XEN_INTERFACE_VERSION__)
>>>   #if __XEN_INTERFACE_VERSION__ != __XEN_LATEST_INTERFACE_VERSION__
>>>     #error ...
>>>   #endif
>>> #else
>>>   #define __XEN_INTERFACE_VERSION__ __XEN_LATEST_INTERFACE_VERSION__
>>> #endif
>> 
>> Well - see Ian's reply. If the values match (granted textually rather
>> than by value), there should be no compiler warning in the first
>> place.
> 
> Hmm, maybe this is the problem: the value from the command line is
> (textually) __XEN_LATEST_INTERFACE_VERSION__ while the value from the
> #define is the _value_ of __XEN_LATEST_INTERFACE_VERSION__ due to the
> pre-processor having replaced it already.

No, that replacement happens after having expanded
__XEN_INTERFACE_VERSION__ at use sites , not when
#define-ing it.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel