On Fri, Dec 6, 2013 at 12:03 PM, Alin Serdean <aserd...@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 [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
