Support for building with CMake

[insertinterestingnamehere]

Having a CMake build system available makes it a lot easier to build with a variety of compilers in a variety of environments. In particular, it makes it a lot easier to build things on Windows. Is there interest in this? I'm considering implementing this myself, though it'll probably take a while since I have several side projects going at the moment.

[jeffhammond]

Speaking only for myself, and perhaps in violent disagreement with others, I think CMake is terrible and a huge waste of time. Windows is not used in high-performance computing anywhere, so that is a poor motivation for CMake. Other than colorized output and a litany of usability problems, what else does CMake bring to the table?

I prefer Autotools in general, but in the case of BLIS, I think "if it ain't broke, don't fix it" applies.

References

• https://blogs.gentoo.org/lu_zero/2006/09/06/cmake_why/
• http://suckless.org/sucks/ (search for cmake)
• https://blog.flameeyes.eu/2008/01/im-not-an-happy-maintainer-working-with-cmake

[insertinterestingnamehere]

Reading through the links, the main issues that people seem to have are that CMake has a difficult syntax and is tricky for beginners to pick up. I can't say that's wrong, but there really isn't any cross-platform build system that doesn't have those issues. Speaking as someone who maintains the build system for a fairly large C++ library and mixed C++/Python library myself, CMake has made it vastly easier to support different compilers, build tools, and operating systems. I've also found that it scales well when managing larger projects with a more modular layout.

All that aside, the assertion that no one needs HPC libraries on Windows is dubious at best. End users on Windows are less likely to be linking directly against BLAS-like libraries, but the authors of higher level languages and numerical libraries still need that sort of functionality available on all the platforms they support.

That's just my two cents though. Others' opinions are certainly still welcome.

[jeffhammond]

Name one machine on the top 500 list of supercomputers than runs Windows. I don't know a single serious scientific computing user that does so on Windows. Sure, there's Matlab, but Matlab doesn't need a build system. Major HPC projects like MPICH and Open-MPI no longer support Windows.

The best way to do HPC on Windows is to run a Linux VM. The performance isn't going to be bad, because the first-order problem is Windows, not the virtualization.

[insertinterestingnamehere]

I'm surprised that the value of Windows support is even a question. Python, R, and Julia all have many users that run scientific code on Windows. MKL, OpenBLAS, and Eigen all support Windows to one extent or another. It's functionality that's valuable to a lot of people. Even Matlab has to get high performance linear algebra routines from somewhere.

I use Windows as my primary development environment, and I'm not the only person I know that does that. I have several Linux and BSD virtual machines that I use to test the code I write in different build environments with different compilers, but I only use them for tesing. I've never had the kind of issues you're implying exist on Windows. Most of the issues I've seen stem from the fact that many developers either don't bother or are ill-equipped to test for Windows compatibility and debug any issues that come up. There are some longstanding ABI incompatibilities between the different compilers on Windows that have yet to be resolved, but I'm optimistic that progress will be made on that front in the near future.

Windows support aside though, having a CMake setup would still help with modularity and versatility on Unix-based platforms.

[poulson]

As a happy resolution to this, it was just announced that Windows 10 will support bash, so there is a good chance that this will include autotools et al.

[insertinterestingnamehere]

Yes, hopefully that'll help with stuff like this. Thanks for pointing that out!

[devinamatthews]

As far as cmake goes, we don't really have the experience nor the interest here to implement it for BLIS. Even autoconf, for which we (I?) have the experience and at least a little bit of interest, is not likely to get any forward momentum since what we have works for everything except Windows. If you wanted to go through the trouble to put something together, perhaps it could be included in some fashion as an alternative to what we have now, but we aren't going to take on support for it.

Concerning Windows, I at least don't have a philosophical opposition to it, but again we just don't have the experience, the interest, nor the time. Also, BLIS is not likely to ever work with MSVC, so you are back to MINGW/Cygwin anyways (I think Cygwin maybe we could look into supporting).

[insertinterestingnamehere]

@devinamatthews great, thanks for clarifying. That makes sense. I'm hoping clang on Windows could provide the needed ABI compatibility along with better support for inline assembly, but getting that all to work is a long way off. I figured it would be good to start somewhere.

[gaming-hacker]

i agree cmake is the biggest piece of bloated #!@#$$ since microsoft windows. if you can't write a makefile from scratch and compile this small lib, maybe you shouldn't be using this lib.

[jeffhammond]

As @poulson noted already, WSL provides a native Bash environment in Windows. Unfortunately, their networking stack is undebuggable rubbish and I wasted many days trying to get it working from behind a firewall, but many people seem to be able to use it when they have a direct connection to the internet.

[devinamatthews]

I can also confirm at this point that BLIS does compile and the testsuite runs successfully under Cygwin. However, I don't know how hard it would be to generate a "proper" Windows DLL with a manifest and whatever. Also, BLIS will most certainly not work on 32-bit Windows probably ever.

[insertinterestingnamehere]

FWIW, my current best guess on Windows compatibility would be to build BLIS using clang on Windows. Clang, when configured properly, can be used to produce MSVC compatible binaries (no issues with mixed C runtimes) and I believe it still supports the gnu assembler format when doing that. That would make the resulting binary usable in places where full binary compatibility with MSVC is important (e.g. Python extension modules). Some time ago I tinkered with getting the existing makefile running with the version of make provided by MinGW and it looked like it would be doable, but I'm not sure if I'll get back to dig into it more. If the makefile can be coaxed into working with MinGW, in theory an MSVC compatible binary could be made using an MSVC compatible clang frontend.

As far as CMake goes, I've had a lot of luck with it in the past on libraries where build system and toolchain flexibility are critical. That said, different projects have different needs and go different directions. Since there's no interest in using CMake here, I'll go ahead and close the issue.