The Qt Company Decides To Deprecate The Qbs Build System, Will Focus On CMake & QMake

[oleid]

Phew!

[wagaf]

I've always said that if your project has needs not covered by a million other projects out there, you should be looking at your project (and its setup) first.
When build tools developed on the shoulders of decades' worth of knowledge don't do what you need (or aren't easily patched to do it), you're probably doing something wrong.

Yet 50 years after there is stil no good/standard way to build/package C/C++ projects and their dependencies.

Autotools is a pile of crap built over previous crap built over previous crap built over....

Even today CMake is limited and there is no simple way to express a dependency and get everything setup for it automatically as it is the case for any modern language (compiled or not).

[Vistaus]

Yet 50 years after there is stil no good/standard way to build/package C/C++ projects and their dependencies.

Autotools is a pile of crap built over previous crap built over previous crap built over....

Even today CMake is limited and there is no simple way to express a dependency and get everything setup for it automatically as it is the case for any modern language (compiled or not).

What about Waf? They explicitly say:

"Automatic build order: the build order is computed from input and output files, among others
Automatic dependencies: tasks to execute are detected by hashing files and commands"

https://gitlab.com/ita1024/waf/

(and it's not obscure or anything 'cause some of the bigger projects like MPV actually use it)

[reavertm]

Even today CMake is limited and there is no simple way to express a dependency and get everything setup for it automatically as it is the case for any modern language (compiled or not).

I have no idea what you are talking about. add_executable, add_library, target_link_libraries does exactly that for C/C++. It builds dependency graph and implements it in underlying generated makefile. No explicit build deps are needed. Yes, it parses #include directives.
Only for special cases you use add_custom_command. And only if you used it poorly you need explicit add_dependencies, but then it's your fault.
Perhaps you mean system level dependencies like with pkg-config. But then it's different story and not CMake's fault, though it helps there with find_* functions.

[discordian]

I have no idea what you are talking about. add_executable, add_library, target_link_libraries does exactly that for C/C++. It builds dependency graph and implements it in underlying generated makefile. No explicit build deps are needed. Yes, it parses #include directives.
Only for special cases you use add_custom_command. And only if you used it poorly you need explicit add_dependencies, but then it's your fault.
Perhaps you mean system level dependencies like with pkg-config. But then it's different story and not CMake's fault, though it helps there with find_* functions.

I think he means external dependencies like using zlib or gtest in your app, you cant comfortably build external projects your project depends on. CMake has the `ExternalProject` module, but its still a valid critism.
The point though is, that afaik Meson is worse, because you have the dependencies and its URLs hardwired in the build files, and cant eg do an build on an isolated server.

Its a problem no current build system solves nicely alone, but there is conan which sits outside of your projects and manage the dependencies. This means your CMake Project will just use `find_library` and does not care whether you just build that library, if you use a prepared binary from a repository, or if the one installed on your system is used.
CMake + conan is the couple to beat, the first is already defacto standard for C/C++, the other is on its path to becoming one.

[cen1]

I think he means external dependencies like using zlib or gtest in your app, you cant comfortably build external projects your project depends on. CMake has the `ExternalProject` module, but its still a valid critism.
The point though is, that afaik Meson is worse, because you have the dependencies and its URLs hardwired in the build files, and cant eg do an build on an isolated server.

Its a problem no current build system solves nicely alone, but there is conan which sits outside of your projects and manage the dependencies. This means your CMake Project will just use `find_library` and does not care whether you just build that library, if you use a prepared binary from a repository, or if the one installed on your system is used.
CMake + conan is the couple to beat, the first is already defacto standard for C/C++, the other is on its path to becoming one.

CPack supports dependencies afaik, so when you install the deb or rpm all the deps are automatically pulled.

[discordian]

CPack supports dependencies afaik, so when you install the deb or rpm all the deps are automatically pulled.

That would surprise me, it does not do anything during the build, only on/after the install step. At any rate, it will fall flat as soon as you want to crosscompile, or want to support [building on] Windows.
conceptually you cant do alot during CMakes configure step, you would need the output of the compiled dependencies in that step. conan runs before configuring your project, can pull binaries or sources from repositories and optionally build them, then outputs a CMake file you can include. Appart from including said file, you dont need to change anything, if you depend on libA, which in turn depends on libB then conan will make sure libA sees the libB you specified.
ie. you end up with every project and dependency using the same, specified libB.

[cen1]

That would surprise me, it does not do anything during the build, only on/after the install step. At any rate, it will fall flat as soon as you want to crosscompile, or want to support [building on] Windows.
conceptually you cant do alot during CMakes configure step, you would need the output of the compiled dependencies in that step. conan runs before configuring your project, can pull binaries or sources from repositories and optionally build them, then outputs a CMake file you can include. Appart from including said file, you dont need to change anything, if you depend on libA, which in turn depends on libB then conan will make sure libA sees the libB you specified.
ie. you end up with every project and dependency using the same, specified libB.

Yeah, conan integration the way you describe would be the ideal scenario.

[Weasel]

Yet 50 years after there is stil no good/standard way to build/package C/C++ projects and their dependencies.

Sure there is, write the makefiles manually. It's not even that difficult. No fucking problem if you don't assume users need to install system-wide libraries or headers, which is already a huge pain for users anyway.

Just drop them in a fucking subdirectory (or symlink) of the project and tell the user to do it.

All build systems are literal garbage because they rely on the assumption that you even install that shit system-wide in the first place. Fuck that. It's worse than the Windows registry.

[andreano]

afaik Meson is worse, because you have the dependencies and its URLs hardwired in the build files, and cant eg do an build on an isolated server.

Its a problem no current build system solves nicely alone

Meson *has* solved the problem! A subproject in Meson can be used in 3 ways:

1. find via pkg-config
2. download source code
3. find via pkg-config, with download as fallback.

The third is what most projects should want.