I think mandating clang (or any compiler w/ >= c99 support) would be best too (and I thought we had it in our default cflags).
That will be the least of windows’ problems though—all that posix and linux specific code in core, plus the build system. Ming- or Cyg- win will be the easiest thing to port to. Should probably open an issue to track all the requirements for the windows port. Patrick From: [email protected] [mailto:[email protected]] On Behalf Of Jeff Hammond Sent: Friday, January 8, 2016 11:13 AM To: Jeff Squyres (jsquyres) <[email protected]> Cc: OFIWG Mailing list <[email protected]> Subject: Re: [ofiwg] ofiwg item: supporting other OS's Does libfabric assume C99? MSVC is not a C99 compiler and never will be, according to every source I've ever seen (e.g. http://stackoverflow.com/questions/9610747/which-c99-features-are-available-in-the-ms-visual-studio-compiler, which links to MSFT docs that I cannot access). Of course, Intel and others support a C99 compiler for Windows, but if Windows support implies supporting the platform's default compiler, then we need to worry about what MSVC supports. Perhaps there is some automatic hook for Intel compilers in Visual Studio that mitigates the ISO shortcomings of MSVC. Clang may also be an option (http://www.theregister.co.uk/2015/10/21/microsoft_promises_clang_for_windows_in_november_visual_c_update/). Given the choice between limiting libfabric to a subset of C99 and not supporting Windows, I vote for C99 100 times out of 100. Best, Jeff On Fri, Jan 8, 2016 at 10:57 AM, Jeff Squyres (jsquyres) <[email protected]<mailto:[email protected]>> wrote: On Jan 8, 2016, at 1:15 PM, Hefty, Sean <[email protected]<mailto:[email protected]>> wrote: > > As a discussion item for the next ofiwg, the topic has come up (again) about > supporting other operating systems, specifically Windows and Solaris. I would imagine that supporting Solaris with the configury/build/sockets providers wouldn't be too difficult...? I don't know much about Windows to comment on it. > At least two development teams have asked about support outside of Linux. > The desire is to code only to libfabric, with it dealing with differences in > the underlying interfaces. This is partially driven by the socket provider > support inside libfabric, which allows for applications to remove their > support for sockets. > > This in turn is driving the need for the sockets provider to focus on > performance and scalability, rather than just functionality, which was the > original goal. Is it worth forking the sockets provider -- one for "simple" correctness (and not performance), and another optimized provider for sockets? -- Jeff Squyres [email protected]<mailto:[email protected]> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ ofiwg mailing list [email protected]<mailto:[email protected]> http://lists.openfabrics.org/mailman/listinfo/ofiwg -- Jeff Hammond [email protected]<mailto:[email protected]> http://jeffhammond.github.io/
_______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
