On Mon, Nov 18, 2013 at 8:51 AM, Ben Pfaff <b...@nicira.com> wrote: > On Mon, Nov 18, 2013 at 08:42:12AM -0800, Gurucharan Shetty wrote: >> On Mon, Nov 18, 2013 at 8:30 AM, Ben Pfaff <b...@nicira.com> wrote: >> > On Mon, Nov 18, 2013 at 07:43:28AM -0800, Gurucharan Shetty wrote: >> >> windefs.h will be included inside config.h. Since config.h >> >> should ideally be included by all the header files, windefs.h >> >> will automatically be included while compiling on windows. >> >> The file is eventually expected to have some typedefs >> >> and #defines to make code compile on windows. >> >> >> >> Signed-off-by: Gurucharan Shetty <gshe...@nicira.com> >> > >> > I have mixed feelings about this because it starts to mix platform and >> > compiler dependencies. If one were to use GCC (from mingw) as the >> > compiler, then the "typedef char bool;" would not help, it would >> > actually prevent compiling. In fact, I'm not sure how it helps with >> > MSVC, since presumably that compiler doesn't have <stdbool.h> and will >> > complain when we try to include it? >> >> The way the windows port (which is a work in progress) is structured >> right now in an internal repo is >> to have the following headers in include/windows. Most of the files >> are empty to prevent compiler complaints. I guess, it also helps to >> prevent multiple #if WIN32 in the .c files of the upstream repo. > > That's reasonable in some cases, I agree. But in this particular case I > think it would be better to simply create a stdbool.h that implements > what C99 wants in that header (which is "bool" and "true" and "false" > and another macro). I think that, if we can implement individual > headers in a straightforward way, then it is generally better to do that > than to throw everything into a single header that is auto-included via > config.h.
Okay. I will abandon this patch till a later time when it may actually be needed. > > ... > >> Now, without those header files and some changes in the .c files, any >> of the patches that I supplied in this patch series won't successfully >> compile using the visual c++ compiler. My idea was mainly to send in >> patches that does not hurt the compilation in any other platforms >> (i.e., linux or freebsd) and also prep the structure of the upstream >> repo so that other code can move in. >> >> Do you feel that individual patches for the windows port should >> compile when using the visual c++ compiler. >> >> Also, as you mentioned, if we use gcc in mingw, that will be a >> problem. Do you have a nicer idea? > > Well, do you have an opinion whether the port should support Windows as > a platform or specifically Windows-on-MSVC as a platform? I haven't > been sure what the exact goal is; if it's only to support MSVC, then > worrying about GCC is moot and I'll stop doing that. I haven't thought about the larger picture about support for gcc. I guess, it does not hurt to make the port such that it will work both on 'gcc' and 'visual c++'. But if it gets uglier and harder, may be we can take a call later. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
