I recently completed writing an implementation of the Octave build system using CMake (3.17+). You can check it out at https://sourceforge.net/p/gnu-octave-cmake-build/code.
The reason I wrote this is because I was finding it difficult to figure out a set up where I would be able to use code analysis and assistance features. Hence, this CMake implementation makes it easier to set up a development environment in various IDEs like CLion, Eclipse, CodeBlocks, etc. I use CLion as my daily driver, so support will be best for CLion.
This implementation also allows for native development, building, and packaging on Windows (ie. without using an MSYS shell). However, it still does require an installation of MSYS2.
Usage of Autotools is not completely eliminated because of the usage of gnulib. However, the bootstrap, configuration, and build are all handled automatically at build-time in parallel with the rest of the build.
In general, configuration performance is better than when using Autotools, and build performance is improved through the optional usage of unity builds and precompile headers as well as the Ninja build system. A lot of the configuration performance is lost though the attempted emulation of the format in which Autotools configures some files like
build-env.cc. Such code could be targeted for optimization in the future.
Relatedly, there are a few areas which are very hacky because of the need to emulate the output of Autotools to ensure that various systems like
mkoctfile are usable. It is also quite difficult to export a full build environment when using CMake, so the generation of some files is very complex and fragile. I don’t really have a better solution than what is in there at the moment, but I’m just going to acknowledge that the code is kind of gross.
- Sphinx documentation for CMake commands, variables, and modules.
- Release distribution and NSIS Installer generation using CPack.
- An experimental version of
- Experimental parallel testing using CTest (currently slower than the existing testing framework because of the startup time).
- The script
run-octave-envwhich will set up environment variables when sourced. This can make it easier to attach a debugger in various IDEs like CLion, which allows a file to be sourced prior to running the executable, or if you just want to use an executable directly from the command line.
- Support for spaces in the source and build directory paths.
- Multi-config support (CMake 3.20+).
- Easier usage of
- Unity builds.
- Precompile headers.
- Fewer reconfigurations required prior to rebuilding after modifying script files.
- Easy creation of Octfile projects when using the CMake config module.
- Lots of bugs, probably.
Tested systems (sub-bullets are cross-configuration targets):
- Alpine Linux (x86_64-alpine-linux-musl)
- Arch Linux (x86_64-pc-linux-gnu)
- Cygwin (x86_64-pc-cygwin)
- Debian 11 (x86_64-linux-gnu)
- Fedora 34 (x86_64-redhat-linux)
- FreeBSD 13.0 (x86_64-unknown-freebsd13.0)
- MSYS2 (x86_64-pc-msys)
- MSYS2 MinGW64 (x86_64-w64-mingw32)
- MSYS2 MinGW32 (i686-w64-mingw32)
- MSYS2 UCRT64 (x86_64-w64-mingw32)
- macOS Big Sur (x86_64-apple-darwin20.1.0)
- openSUSE Leap 15.3 (x86_64-suse-linux)
- Windows 10 (x86_64-w64-mingw32)
- Windows Subsystem for Linux - Debian 11 (x86_64-linux-gnu)
Hopefully this is helpful to some people.