In the beginning there where three build systems we where trying to support for QueryC++. These where bare bones Make, waf.io with a custom extension written by Steinwurf ApS, and finally CMake.

In this update. I mentioned that we we are reducing the build systems to only CMake and to my surprise (lol not!) some people wrote me that the choice was stupid. Some argued the case for Make, waf, and xmake, the latter being a system I briefly had considered. Others argued the case for Bazel Most arguments were very valid and most where things I had considered, but CMake still won. A thing I will say here is that there where some very compelling arguments for Bazel I had not considered. Although these did not make me switch QueryC++ to Bazel, they have made it so it is a build system I will explore more (spoiler it has something to do with Go).

Now why did CMake win? Basically it boils down to widespread usage and ease of use. CMake is, if you dedicate like 24 hours to it, easy to use, both for defining and setting up you own project and also configuring external dependencies. FetchContent plays a big part here. Both in terms of handling external dependencies, but also the ease with which we can make QueryC++ available to others. Additionally the fact that CMake is available for (almost) all platforms means that we easy can provide it to a large audience. A very huge plus.

Another positive of CMake is that I have seen examples of projects depending on both waf and Bazel adopt an approach that could make CMake based dependencies available in these projects, with relatively low effort. Again speaking to the benefit of CMake and its wide spread usage.

So basically this is why it won. Now we may switch in the future who knows. Maybe Bazel proves a better build system. But for now we stick with it.

Support for using QueryC++ via FetchContent

AND WE OFF!!! I finally had time to spend some time understanding FetchContent and how to make a package available. So now QueryC++ can be used via FetchContent. We are really excited about this as previously people have been copying the files by hand. But that ends with QueryC++ 4.0!

For a small teaser you can test it with the small example below. First a very simple C++ program, note that the valid function will not be available in the final release of QueryC++ 4.0

#include <querycpp/querycpp.hpp>

#include <iostream>

int main(void) {

    std::cout << querycpp::valid() << "\n";
}

Followed by the CMakeLists.txt file.

cmake_minimum_required(VERSION 3.18)

project(test_querycpp VERSION 4.0.0 DESCRIPTION "Test QueryC++" LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED True)
set(CMAKE_CXX_FLAGS "-Wall -Wextra -O3")

include(FetchContent)

FetchContent_Declare(
    querycpp
    GIT_REPOSITORY https://gitlab.com/looopTools/querycpp.git
    GIT_TAG querycpp_four
)

FetchContent_MakeAvailable(querycpp)

add_executable(t main.cpp)

target_include_directories(t PRIVATE querycpp fmt::fmt)
target_link_libraries(t querycpp fmt::fmt)

This can be compiled by the following series of command on Linux and macOS where CMake and clang++ or GCC++ is installed.

mkdir build
cd build 
cmake ..
make 

These steps will automatically download QueryC++ and make them available for your code using FetchContent.

If you are wondering why we reference fmtlib, it is because it is a dependency of QueryC++. At least it is until compilers start supporting format truly.

I CANNOT STRESS ENOUGH: QueryC++ 4 is not ready for production use and this only servers as an example.

./Lars