Support for building with CMake about blis HOT 12 CLOSED

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.

from blis.

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.

from blis.

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.

from blis.

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

from blis.

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.

from blis.

from blis.

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.

from blis.

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

from blis.

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

from blis.

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

from blis.

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.

from blis.

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.

from blis.