[ovs-dev] [PATCH 7/8] windefs: Add a placeholder for common definitions for windows.

[Ben Pfaff]

On Mon, Nov 18, 2013 at 08:42:12AM -0800, Gurucharan Shetty wrote:
> On Mon, Nov 18, 2013 at 8:30 AM, Ben Pfaff <blp at 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 <gshetty at 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.

...

> 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.