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

[Alin Serdean]

I think we should use _WIN32 (it is predefined for both Win32 and Win64) :).

http://msdn.microsoft.com/en-us/library/b0084kay.aspx

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