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

Alin Serdean aserdean at cloudbasesolutions.com
Fri Dec 6 19:35:45 UTC 2013


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
+#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