Cmake build vs make upgrade#
Cmake build vs make code#
Cmake build vs make windows#

We are happy that the facelift has worked out well. All this will come together in the next official feature This definitely will require further stitching the CMake code. The packaging of MonetDB on all supported platforms, e.g.

Cmake build vs make upgrade#

A complementary part that calls for attention is to upgrade But what about the rest?Įvery tool has its limitations in terms of functionality. (CMake or others) to handle building and linking. A clean API makes it easier for the build system Need to be exposed to upper layers and which should not. cleaning up the interfaces between all layers in MonetDB, e.g. But a new decade calls for change, so we took off our old jacket and embraced the new

Cmake build vs make code#

–target installĪ facelift like this requires all involved in the development and maintenance of the code to recognise its necessity.ĭespite the fact that CMake has already been around since 2000, the proper working of the old setup has hindered such a Compiling the “default” branch of MonetDB for debugging is a common action.īootstrap+configure/cmake -DCMAKE_BUILD_TYPE=Debug Illustrative are the numbers obtained on a development laptop with Intel(R) Core(TM) i7-6560U, 16G RAM running ArchLinux.

Cmake build vs make windows#

Faster builds?Īlthough not a goal of this change, we observed some faster builds, mostly on Windows and macOS, where the old autogen Terms of libraries and functions), the build phase, the test phase and the packaging phase (rpm, deb, tarball, etc).Īll of this for all platforms supported (Linux, Windows, macOS).The commands are the same for each platform so that aĭeveloper can work on any platform. The main benefit is that CMake does all steps, including the configure phase (detect what a platform has to offer in It was an excellent learning step and convinced us to prepare for a big jump.įinally, this is achieved in June 2020, when the code base has become fully controlled by CMake.

The first CMake infrastructure for MonetDB. A major step was taken by Pedro Ferreira with the creation of It became clear that this ‘oldy’ had to jump the fence. However, with the experience of a fork of MonetDB, called program MonetDBLite using CMake, Switching to CMakeĪutomake and friends have been very stable over the years. Large program which required constant laborious attention to follow the OS versions and to support the ever-growingĬollection of linked libraries. It started out as a small, self-documented Python program. We started in 1996 with our own tool autogen to handle this.Īutoconf files for Unix systems, and Microsoft Visual Studio Linking the libraries needed, and to cope with the exceptions raised by the Linux (different flavours), Unix, macOSĪnd Windows platforms. The old build systemĪ critical component in this process is the collection of tools we use to build the system from source, finding and Its functionality has increased significantly and its maturity has been brought to a level that more enterprise-classĬompanies are using MonetDB in their core business offerings today. With the obligation to make it available on many platforms.įor two decades, the code has been built and tested nightly on ~20 different platforms. Initially developed for Unix only, it became clear that moving MonetDB into the open-source community in 2003 comes The MonetDB project runs since early 1993 when the first lines of code were written.