[ovs-dev] [PATCH] lib: Bypass include_next preprocessor directives on Windows platform

Gurucharan Shetty shettyg at nicira.com
Fri Dec 6 20:30:42 UTC 2013


On Fri, Dec 6, 2013 at 12:03 PM, Alin Serdean
<aserdean at cloudbasesolutions.com> wrote:
> I think we should use _WIN32 (it is predefined for both Win32 and Win64) :).
>
> http://msdn.microsoft.com/en-us/library/b0084kay.aspx
I see what you mean. You are correct. I was referring to the WIN32
defined through config.h.
So your change is fine with me.

>
> Kind Regards,
> Alin.
> ________________________________________
> From: Gurucharan Shetty [shettyg at nicira.com]
> Sent: Friday, December 06, 2013 9:47 PM
> To: Alin Serdean
> Cc: Alessandro Pilotti; Ben Pfaff; dev at openvswitch.org
> Subject: Re: [PATCH] lib: Bypass include_next preprocessor directives on Windows platform
>
> On Fri, Dec 6, 2013 at 11:35 AM, Alin Serdean
> <aserdean at cloudbasesolutions.com> wrote:
>> Signed-off-by: Alin Serdean <aserdean at cloudbasesolutions.com>
>> ---
>>  lib/string.h |    4 ++++
>>  1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/lib/string.h b/lib/string.h
>> index 2b7b454..6981742 100644
>> --- a/lib/string.h
>> +++ b/lib/string.h
>> @@ -17,7 +17,11 @@
>>  #ifndef STRING_WRAPPER_H
>>  #define STRING_WRAPPER_H 1
>>
>> +#ifdef _WIN32
>
> The above should be WIN32 and not _WIN32. Otherwise, I feel it is fine.
> Ben,
> Do you have any comments?
>
>> +#include <../include/string.h>
>> +#else
>>  #include_next <string.h>
>> +#endif
>>
>>  /* Glibc 2.7 has a bug in strtok_r when compiling with optimization that can
>>   * cause segfaults if the delimiters argument is a compile-time constant that
>> ---
>>
>> Kind Regards,
>> Alin.
>> ________________________________________
>> From: Gurucharan Shetty [shettyg at nicira.com]
>> Sent: Friday, December 06, 2013 9:13 PM
>> To: Alin Serdean
>> Cc: Alessandro Pilotti; Ben Pfaff; dev at openvswitch.org
>> Subject: Re: [ovs-dev] Windows port status
>>
>> On Fri, Dec 6, 2013 at 9:42 AM, Alin Serdean
>> <aserdean at cloudbasesolutions.com> wrote:
>>> Guru can you do a quick review over the following:
>> Can you please send as a inline mail with a proper commit message (you
>> can look at SubmittingPatches or dev archives for examples) and a
>> Signed-off-by.
>>
>>> diff --git a/lib/string.h b/lib/string.h
>>> index 2b7b454..6981742 100644
>>> --- a/lib/string.h
>>> +++ b/lib/string.h
>>> @@ -17,7 +17,11 @@
>>>  #ifndef STRING_WRAPPER_H
>>>  #define STRING_WRAPPER_H 1
>>>
>>> +#ifdef _WIN32
>> We do not define _WIN32 but rather WIN32.
>>> +#include <../include/string.h>
>>> +#else
>>>  #include_next <string.h>
>>> +#endif
>>>
>>>  /* Glibc 2.7 has a bug in strtok_r when compiling with optimization that
>>> can
>>>   * cause segfaults if the delimiters argument is a compile-time constant
>>> that
>>>
>>> This will solve the include_next from the lib folder.
>>>
>>> Kind Regards,
>>> Alin.
>>> ________________________________
>>> From: Alin Serdean
>>> Sent: Tuesday, December 03, 2013 10:45 PM
>>> To: Gurucharan Shetty; Alessandro Pilotti
>>> Cc: Ben Pfaff; dev at openvswitch.org
>>>
>>> Subject: RE: [ovs-dev] Windows port status
>>>
>>>> #ifdef _WIN32
>>>> #include <../include/string.h>
>>>> #else
>>>> #include_next <string.h>
>>>> #endif
>>>
>>> The bold include is to point to the Visual Studio includes that is why it
>>> has a really funny path :). But this is what I thought maybe you have a
>>> better suggestion. I also thought to force the visual studio includes first
>>> before the OVS specific includes but that would involve a lot of more hacks.
>>>
>>> I would not want to copy windows' includes to the OVS project that would
>>> bring a lot more problems.
>>>
>>> Kind Regards,
>>> Alin.
>>> ________________________________________
>>> From: Gurucharan Shetty [shettyg at nicira.com]
>>> Sent: Tuesday, December 03, 2013 8:29 PM
>>> To: Alin Serdean
>>> Cc: Ben Pfaff; dev at openvswitch.org
>>> Subject: Re: [ovs-dev] Windows port status
>>>
>>> On Mon, Dec 2, 2013 at 2:20 PM, Alin Serdean
>>> <aserdean at cloudbasesolutions.com> wrote:
>>>> Hey,
>>>>
>>>> Continuing patches for the windows build.
>>>>
>>>> The next problem that we are facing is that the include_next directive is
>>>> missing from the VStudio compiler.
>>>>
>>>> The affected files will be:
>>>> include/linux/types.h
>>>> #include <sys/types.h>
>>>> #ifndef _WIN32
>>>> #include_next <linux/types.h>
>>>> #endif
>>>
>>> Since linux/types.h is only included from linux specific source files,
>>> we would be excluding those source files from getting compiled in
>>> windows build.
>>>
>>> I see linux/types.h being included only in the datapath
>>> directory(which is linux datapath), lib/dpif-linux.c and
>>> lib/netdev-linux.c.
>>> If you see lib/automake.mk, the dpif-linux.c and netdev-linux.c are
>>> only included when LINUX_DATAPATH is defined. So I don't see this
>>> being a problem for windows build.
>>>
>>> As an example template, we can have something like this in lib/automake.mk
>>> +if WIN32
>>> +lib_libopenvswitch_a_SOURCES += \
>>> + lib/dpif-windows.c \
>>> + lib/dpif-windows.h
>>> +endif
>>>
>>>
>>>>
>>>> lib/string.h
>>>> #ifdef _WIN32
>>>> #include <../include/string.h>
>>>> #else
>>>> #include_next <string.h>
>>>> #endif
>>>>
>>> Are you suggesting that we copy windows' string.h into the "include"
>>> directory? If so, we should instead put it in "include/windows"
>>> directory and include that directory only when we are building on
>>> windows.
>>>
>>> ex:
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>> @@ -10,6 +10,11 @@ ACLOCAL_AMFLAGS = -I m4
>>> SUBDIRS = datapath
>>>
>>> AM_CPPFLAGS = $(SSL_CFLAGS)
>>> +
>>> +if WIN32
>>> +AM_CPPFLAGS += -I $(top_srcdir)/include/windows
>>> +endif
>>> +
>>> AM_CPPFLAGS += -I $(top_srcdir)/include
>>> AM_CPPFLAGS += -I $(top_srcdir)/lib
>>> AM_CPPFLAGS += -I $(top_builddir)/lib
>>>
>>> Ben probably has better ideas here.
>>>
>>>
>>>> Does anyone else have a better suggestion?
>>>>
>>>> Kind regards,
>>>> Alin.
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev at openvswitch.org
>>>> http://openvswitch.org/mailman/listinfo/dev



More information about the dev mailing list