[ofiwg] ofiwg item: supporting other OS's

[Jason Gunthorpe]

On Fri, Jan 08, 2016 at 02:48:47PM -0800, Jeff Hammond wrote:
>    It's not a huge swath of cases.  It is a very large number of instances
>    of a very small number of cases.  I suspect that your huge swatch of
>    cases boils down to {Linux,BSD} x
>    {x86(_64),ppc{32,64,64le},arm{32,64}}.  I guess there might be a mips
>    or a sparc in there, but what you are really saying here is that you
>    think two instantiations of POSIX represent the entirety of computing.

? gcc runs on almost everything, and generally isn't hard to
install. Solaris, Windows, AIX, Mac OS, no problems. Most common cases
have recent binary builds available.

>    You're right.  libfabric should use as many features from C11 as
>    possible and expect everyone whose machine doesn't have GCC 5.3 and
>    Clang 3.8 on it to build their C compiler toolchain from source.

I wouldn't be that extreme.

C11 support requires gcc 4.9 for full compiler features (yes, I know
the library side is missing) and that is now nearly a two
year old compiler.

If it makes sense I wouldn't shy away from C11 features, many are very
handy. And I wouldn't do a Windows port without a C11 compatible
compiler.

>    Let's make life miserable on everyone running Debian stable,
>    CentOS 6.x, etc.

CentOS 6 & 7 have RH supported packages for gcc 4.9 available via yum.

Debian stable already ships gcc 4.9

A binary install is avaiable for Mac OS

A binary is avaiable for Windows.

Clang 3.7 equally supports C11, and provides binaries for windows and
x86 linux.

Don't overstate how hard the typical case is.

Yes, the atypical case could be very hard, but 

>      The old OFA effort to port the stack to Windows, IMHO, made a big
>      mess. Ideologically requiring an old-at-the time MSVC compiler
>      certainly contributed. Use a compiler that makes the port easy.
> 
>    Why not just say "use an operating system that makes the port easy"?
>    It's completely ridiculous to argue that OS portability matters but
>    compiler portability doesn't.  Be intellectually consistent and oppose
>    the Windows port or stop discussing this issue altogether.

That doesn't make any sense. A OS port is user a user visible top
level feature. The toolchain is just a means to an end.

I've got several software projects that are OS portable but not
compiler portable (in the sense that they fully support many
compilers, but often not the broken OS default one). I don't think
that is inconsistent at all.

Those projects require work to setup a build environment on certain
OSs. That is less work than forever carrying patches for broken
compiler support.

It isn't for every project, but it is a very valid, and productive,
way of approaching the problem.

Especially now that the C standard bodies have worken up and are
producing new standards more often. The C++ world feels this especially
acutely.

Jason