Build systems

[christoph-conrads]

As of today, there are three different build systems in LAPACK:

• Makefiles-only,
• CMake, and
• Meson.

The Meson build is incomplete and unmaintained since its introduction in January 2019. The CMake and the Makefile-only build are not identical: The -frecursive flag is missing. Having more than one build system has at least three effects:

• It increases the amount of work,
• the issues Segmentation fault when testing xeigtstz #276 and Segfault in ./EIG/xeigtstz #335 do not occur when building with CMake but
• only the CMake-based builds may crash when LAPACK is called concurrently, see the comment about the need for -frecursive in PR #486.

Especially the last point is great because even if someone delivers an accurate problem report, it is impossible to retrace the issue when you built with Makefiles.

I strongly suggest to stick with one build system.

[martin-frbg]

To add to the list, CMake builds currently (appear to) support the option to build only select parts of the library (REAL, DOUBLE, COMPLEX and/or DOUBLE COMPLEX), while Makefile-only builds do not. (I have changed the Makefiles in the copy we distribute with OpenBLAS and could produce a PR if desired - would need to rediff to leave out some changes not relevant here)

[christoph-conrads]

CMake builds currently (appear to) support the option to build only select parts of the library (REAL, DOUBLE, COMPLEX and/or DOUBLE COMPLEX)

This option worked the last time I tried it (around May 2020).

The CMake build has several options, I list the most important ones for me here:

• building shared or static libraries
• enabled or disabling tests
• 64- or 32-bit indices
• optimized and debugging builds
• options for matrix generator library (TMG), usage of other BLAS libraries, BLAS++, LAPACK++...

[thijssteel]

Good idea. Builds working on my machine with make but not on the ci with CMake has driven me crazy a few times.

Technically, i think the Makefile also supports a lot of those options (you can just edit your make.inc). If you want a build without the tests you can build with make lib. But crucially, building a shared library is not supported. Most people use LAPACK as shared library so that makes CMake the clear winner for me.

If we end up going for it, I suggest we add some extra build instructions to the readme. How to build and run the tests, how to add flags, especially the frecursive flag. Perhaps even some small note on how to use the shared library.

[martin-frbg]

I suspect there will be many patches floating around already (e.g. in linux distributions that package lapack) to build shared libraries with gmake. Should not be too complicated to add a BUILD_SHARED option to make.inc like the BUILD_DEPRECATED that is already there (and both are pretty obscure in the CMake build unless one already knows that ccmake and cmake-gui exist).

[christoph-conrads]

Should not be too complicated to add a BUILD_SHARED option to make.inc like the BUILD_DEPRECATED that is already there (and both are pretty obscure in the CMake build unless one already knows that ccmake and cmake-gui exist).

There is no need to work with ccmake to set any of these options. You can use the command line similar to the configure script generated by autotools:

$ cmake -DBUILD_SHARED_LIBS=ON -DBUILD_COMPLEX=OFF -DBUILD_DEPRECATED=ON -- ../lapack/
[snip]
-- Build deprecated routines: ON
-- Build single precision real: ON
-- Build double precision real: ON
-- Build single precision complex: OFF
-- Build double precision complex: ON
[snip]
$ git -C ~/lapack rev-parse HEAD
6e125a41a7d4905d905a7467d3239d3f0d14b22c

[martin-frbg]

You certainly can, my point is that there is no obvious documentation except reading the CMakelists.txt (whereas the README points one to the preconfigured make.inc files for gmake). ccmake and cmake-gui show a list of available options, but this will be lost on anyone new to cmake.

[langou]

If we write a documentation on how to use CMAKE, we can use me as the guinea pig user since I have never used CMAKE.

Reading the whole conversation, I feel that the Makefile is in LAPACK there only for me. ;)

Well, I do not know.

Yes: maintaining several build system leads to inconsistencies. So I see the argument to only have one. (Whether it be CMAKE, make or meson.) (Oh yes, I have never used meson either, if you wonder.)

I am worried about moving to CMAKE because, not only do I not know how to use it, I do not know how maintain it. However it seems like we have a wonderful community who can help, so me not being able to work on this part of the project does not seem an issue, in addition, I probably should learn CMAKE.

All: Please express your opinion in this thread.

It seems that most of us would like to (1) remove make and remove meson; (2) move to CMAKE only; (3) add some good documentation on how to use CMAKE. Fine with me.

I am going to send a few emails to other package maintainers here and there to ask how they are doing and what their opinion on this issue is.

@martin-frbg: how is this done in OpenBLAS?

[martin-frbg]

OpenBLAS has Makefiles as its "traditional" build system that is "known to work", and CMAKE as an originally user-contributed alternative that still spits out a warning that the files it generates may not correspond exactly to what a Makefile build would do.
I do not like CMAKE much, but I have learned to create working (though perhaps sometimes unorthodox) cmake build files. In my opinion, the Makefiles should remain (and I believe gmake is still more widespread than cmake). I do not know the history of the meson support - if this was a one-time "thrown over the fence" contribution that nobody knows or cares enough to keep updated, I guess there is little point in keeping it around.

[christoph-conrads]

I do not know the history of the meson support - if this was a one-time "thrown over the fence" contribution that nobody knows or cares enough to keep updated, I guess there is little point in keeping it around.

The Meson build was parachuted into LAPACK in PR #311.

[martin-frbg]

Hm. If it got accepted into 3.9.0 (even if just as a proof of concept), it would look a bit strange to throw it out again with the very next release...

[langou]

I contacted @therault so that he can give us his opinion, here is what @therault says. Thanks @therault!

Open MPI uses only autoconf (automake, autoconf, configure, Makefiles).

For PaRSEC and DPLASMA, we only use CMake, and to help users who are used to configure, @abouteiller made a script that uses the syntax of configure and calls CMake with its own syntax.

I know of one major project that tried to maintain both configure and CMake. It slowly evolved in a situation where 100% of the features were available in CMake, and less and less new features were supported in configure. I believe that they have stopped maintaining the configure version.

Maintaining two build systems for a code is hard: in theory, the build system should work with any code, and thus maintaining two should be possible (with a high cost for the maintainers, to keep them in sync, which is the reason why the configure was dropped in that other project, the maintainer decided he had better things to do with his time). In practice, it is sometimes necessary to adapt the code to the build system to make things cleaner. When that happens, one of the two build systems needs to use workarounds and hacks to behave as the other one and in accordance with the code.

In the end, CMake or configure, both will disappoint. We are programmers / mathematicians / we do algorithms... Spending time to understand why on that machine, with this combination of compilers and flags, the code doesn't compile properly, nobody likes that. Worse, trying to find how to do that thing or that other using CMake or autoconf will drive you up the wall :) Working with both, I can guarantee you will complain about both of them :) Maintaining a single one is a sure way to complain twice less.

Today, I'm in favor of CMake for a single reason: CMake does a good job at generating Ninja files instead of Makefiles. Ninja compiles PaRSEC twice to three times faster than Make -j. Now, maybe configure/autoconf can also generate Ninja files, I never tried... If you never tried ninja before, and if LAPACK has a CMake version, I suggest you try cmake -G Ninja (after installing Ninja on your machine). To compile, you call 'ninja' in the directory where you executed cmake instead of 'make'. You'll see, that's amazing :)

[abouteiller]

I am happy to contribute said configure-to-cmake glue script to LAPACK if that's something you are interested in.
(to clarify, that script is not autoconf/m4 based, it is a simple script that converts configure --with-feature=value into a call to cmake -DFEATURE=value, with a little more polish).

[martin-frbg]

LAPACK does not even use configure - and I agree it would probably be a pain to keep an autoconf/automake/configure-based system concurrent with cmake, with the autotools themselves constantly "evolving" and being dependent on m4 macros and whatnot.