Is it normal to resort to using superbuilds?

Usage
1

I’m writing an app, which is using blake3, libsodium, libwebsockets(git master, because I have a patch upstream not in the release yet to support IPV6 PREFER_SRC_PUBLIC), google test, and a custom library.

Libsodium uses autotools configure files.

All of these are a bit esoteric and not normally installed on Linux machines, if they are they are often old versions.

So I went with a superbuild.

From the main superbuild, to each ExternalProject_Add function
I am doing
CMAKE_ARGS “-DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}/install”

And then for my app that needs to link all those libraries I am doing
“-DCMAKE_CXX_FLAGS=-I ${CMAKE_BINARY_DIR}/install/include”
“-DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}/install”
“-DCMAKE_INCLUDE_PATH:PATH=${CMAKE_BINARY_DIR}/install/include”
It’s basically making everything build static libs in like a standard install prefix in the build directory, and letting all of the dependent libs install themselves into a prefix I can later use to link with and use the standard include path with.

Not all the dependencies use native cmake, so I figure it is more reproducible to do that and then use find_library in my main project that needs to link.

Is that like non-standard, or clean enough?

It seemed to be the cleanest thing to do.

If I was using popular libraries, like openssl or gnutls, I’d just use the OS’s libraries.

For my own lib, I am just using what add_library exported, not going back to find_library.

Superbuilds seemed to be a common way to support libraries that use cmake natively, and ones that don’t. They also happen at configure time, so you can build libraries before having a build dependent on them.

2

I see another thread about a package manager for CMake, CPM. Very related, yeah this is about managing dependencies cleanly.

And it acts as a wrapper for FetchContent.

So superbuilds=good for dependency management?

3

Superbuilds are (IME) good for packages. The ParaView superbuild is essentially its own distribution management system tailored to building ParaView binaries. Updating dependencies is tedious and time consuming (as it is for any distribution of disparate software), but it also means we’re in control of what is packaged.

Another use case that ParaView’s superbuild infrastructure supports is a “developer mode” (unused by ParaView itself) where it just builds dependencies and then offers a file to give to cmake -C to use those dependencies as the superbuild itself would build it. This can be used to do development against “obscure” libraries in a controlled way.

If the project is standalone, FetchContent-based solutions are good (though @craig.scott has more experience), but if it is intended to be used/distributed with other things or mechanisms, using find_package is generally more flexible as mixing vendored dependencies almost never goes well.