Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Ease
Ease is a Build System for C++ that strive to acheive simplicity. There is no dependancies, no installation you drop off Ease.hpp in your project and can start writing a build function. The build function will be called and the build will start according to the return value of this function. (by Tackwin)
Are you aware of the existing main package managers? vcpkg (1800 packages available) and Conan (claims that 1000 packages are available but the list stops at letter T so I suspect it's cut off).
ah libpq the perl monster on windows generating msbuild files. I wonder if the autotools/configure script could be used on windows instead. The vcpkg recipe is also horrendous: https://github.com/microsoft/vcpkg/blob/master/ports/libpq/portfile.cmake and even requires conditional patching depending on the config relaese/debug
Are you aware of the existing main package managers? vcpkg (1800 packages available) and Conan (claims that 1000 packages are available but the list stops at letter T so I suspect it's cut off).
From a quick searching I found what it takes to compile a Windows executable on macOS, these flags could be very easily turned into a toolchain file and the situation would be similar on Linux as well.
Here is a simple example, Sol2 which requires lua: https://github.com/build2-packaging/sol2
Platform dependence: They seem to involve bizarrely low-level and compiler-specific details. Just look at this from the spdlog recipe:
I've also seen things in build2 recipes involving gcc or MSVC compiler switches. Admittedly, the CMake script for spdlog is also quite complex. But I think that's because it's covering a lot of possibilities of how its dependencies are built that build2, by the sounds of it, ought not have to worry about. CMake gives you platform independent ways to set features on targets so that, in theory at least, you write your build script once and it automatically works across multiple platforms.
Scattered files: In CMake, it's quite common for the build script to be split over multiple files. Most commonly it's a top-level CMakeLists.txt, then another for each subdirectory (often corresponding to a target), plus some utilities in a cmake/ subdirectory. But that is nothing compared to build2. Just look at the build script repo for libpq. What on earth is going on? There are a few top-level files, plus a submodule for the upstream (fair enough), but then absolutely heaps of subdirectories mirroring pq directories, plus softlinks into the upstream submodule. There are others that actually look worse to me but I don't feel comfortable linking to them because I'm not sure what's going on!