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 [shet...@nicira.com] Sent: Friday, December 06, 2013 9:47 PM To: Alin Serdean Cc: Alessandro Pilotti; Ben Pfaff; dev@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 <aserd...@cloudbasesolutions.com> wrote: > Signed-off-by: Alin Serdean <aserd...@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 [shet...@nicira.com] > Sent: Friday, December 06, 2013 9:13 PM > To: Alin Serdean > Cc: Alessandro Pilotti; Ben Pfaff; dev@openvswitch.org > Subject: Re: [ovs-dev] Windows port status > > On Fri, Dec 6, 2013 at 9:42 AM, Alin Serdean > <aserd...@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@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 [shet...@nicira.com] >> Sent: Tuesday, December 03, 2013 8:29 PM >> To: Alin Serdean >> Cc: Ben Pfaff; dev@openvswitch.org >> Subject: Re: [ovs-dev] Windows port status >> >> On Mon, Dec 2, 2013 at 2:20 PM, Alin Serdean >> <aserd...@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@openvswitch.org >>> http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
