[ovs-dev] Windows port status

Alin Serdean aserdean at cloudbasesolutions.com
Fri Dec 6 17:42:06 UTC 2013


Guru can you do a quick review over the following:
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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20131206/ef1aa743/attachment-0003.html>


More information about the dev mailing list