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

[ddriver]

Great going digia, you sure know how to waste developer efforts... over and over again it happens under their leadership.

But hey, at least you have a CoC now, that's gotta count for something.

A shame really, because qmake project syntax is so messy. QBS could have been great, but alas, seems like trendwh0ring gets in the way as it has done for digia many times before.

[andreano]

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.

/usr/local is just a default you're supposed to override. All buildsystems must support that, so package maintainers can override it to /usr.

* Automake: ./configure --prefix=$HOME/.superlocal
* CMake: cmake -DCMAKE_INSTALL_PREFIX=$HOME/.superlocal
* Meson: meson -Dprefix=$HOME/.superlocal

[oleid]

Sure there is, write the makefiles manually. It's not even that difficult.

That doesn't scale very well beyond simple dependency graphs. Also, cross compiling is a huge PITA this way. But you should know that, as a C professional, shouldn't you?

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.

While bundling your deps in source form is a good idea (works very nice with i.e. cmake), it doesn't scale very well with plain Make. For example, when you have a dependency, which is used from N of your targets and this very dependency suddenly needs another dependency itself. Either, you have one huge toplevel makefile, which contains EVERYTHING, or you need to add the new includes and libs to N places.

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.

You should consider refreshing your knowledge on build systems. That isn't true even for autotools.

[Weasel]

/usr/local is just a default you're supposed to override. All buildsystems must support that, so package maintainers can override it to /usr.

* Automake: ./configure --prefix=$HOME/.superlocal
* CMake: cmake -DCMAKE_INSTALL_PREFIX=$HOME/.superlocal
* Meson: meson -Dprefix=$HOME/.superlocal

You're missing the point. A project's directory should -- literally -- contain everything it needs to compile itself. Literally. No exceptions. (yes, you could symlink if you wanted to though)

We're in this mess we're in because of violating this simple rule.

Just like a sandbox, it should be banned to even THINK about accessing a file outside of the project directory. Whoever comes up with that stuff should be executed on the spot.

[Weasel]

That doesn't scale very well beyond simple dependency graphs. Also, cross compiling is a huge PITA this way. But you should know that, as a C professional, shouldn't you?

I have no idea what is a PITA with a simple system. I've no issues cross compiling with MinGW either.

Dependency graphs? All you need are header files. That's fucking it. Just headers. If a library has a dependency on another library and needs some headers from it, it's its own responsibility to supply them -- of course, assuming everyone was sane like me.

Header files are the same whether you cross compile or not. So what the hell do you need build systems for?

Optionally, you could have static libraries (if you don't want to link dynamically), but those are no different than object files, so they're optional.

And obviously, you should compile with sane options like -Wl,-unresolved-symbols=ignore-in-shared-libs since, well, why the FUCK does the build environment care about my RUNTIME environment or even have access to it? It needs to fuck off and just build without caring if it can find the .so or not. That's the runtime loader's job, not the linker's.

The entire thing just stinks of pathetic ass-backwards design where you're just supposed to treat the build environment and the runtime as one and the same, unsurprisingly it's why we have such a massive mess as we are in right now, with these stupid build systems.

People come up with bullshit like "dependency graphs" without realizing it's a problem purely created due to their stupid mentality of how a build process works. Their extremely convoluted ways and can't imagine how it is to simplify it.

While bundling your deps in source form is a good idea (works very nice with i.e. cmake), it doesn't scale very well with plain Make. For example, when you have a dependency, which is used from N of your targets and this very dependency suddenly needs another dependency itself. Either, you have one huge toplevel makefile, which contains EVERYTHING, or you need to add the new includes and libs to N places.

What? Why should a makefile care about header files? (which is what dependencies are)

Makefiles care only about your own project's source files, or your own project's internal static libraries, which is the same thing.

Also, who the hell names the source files manually in makefiles? You realize a makefile can loop through all source files automatically and GCC can automatically generate all the header dependency information from each source file, right?

You should consider refreshing your knowledge on build systems. That isn't true even for autotools.

Well I admit my knowledge is limited, I've no interest in learning any convoluted garbage for something that should be as simple as about 50 lines of code at most.

You know how pathetic it is when you see those build system configs are larger than a hand-written Makefile that automatically builds all .c or .cpp files under a given directory.

[oleid]

What if your source code has a dependency, which needs certain include search paths set? And what if this dependency in turn has other dependencies, which needs certain include search paths?

Do you specify all the include search paths of all your dependencies and their dependencies in all your makefiles?

[Happy Heyoka]

Well I admit my knowledge is limited, I've no interest in learning any convoluted garbage for something that should be as simple as about 50 lines of code at most.

well, I suspect anyone who has ever written code has had moments of feeling that way... unfortunately reality has a way of screwing with those notions.
I ticked off about seven different projects in my head reading through your rant - all required something not because it was the right way to do it, not because it was a good way to do it, but because it was the only way to do it given history, time and money concerns.

And along those lines, I am surprised the Qt folks were dumb enough to fall for the "golden tool" thing (and let's be honest, if you've been doing this for more than five minutes you know what I'm talking about). Spending some time and money improving CMake (and best practice documentation) would have been far better.
There are good and bad ways to use CMake, and stuff that's legacy junk just hanging around for backwards compatibility.
Finding people who can explain that nicely is really hard (some of the KDE folks have made an effort) but again there's 20 years of web stuff explaining badly how to use CMake.

[brrrrttttt]

Weasel hijacks another thread with misguided ranting, *sighs*.

This is a really unfortunate decision. qbs made it much simpler to both build __and__ package a cross-platform Qt application. cmake only provides a subset of its functionality, and with a horrid DSL to boot. meson was never in the game for any non-trivial Qt application, as its Qt support is very immature.

[Alliancemd]

This is good news.
They can reuse years of work and refinement from KDE now(and they do - that branch already has great support for Sanitizers, pulled from KDE's ECM, besides having Find<Package> modules from KWin for all the graphical stuff).
For dependencies, they offer the possibility to use "vcpkg".

I understand that Meson is being hipped and misconceptions are thrown about CMake(most are coming from old CMake, pre modern CMake targets, pre CMake 2.8.12 and people not being familiar with modern CMake) but the tool support(example: All IDEs support CMake), community and work already done around CMake brings a lot more value to them.

[Alliancemd]

Also, who the hell names the source files manually in makefiles? You realize a makefile can loop through all source files automatically and GCC can automatically generate all the header dependency information from each source file, right?

Well, you seem to be doing dependency incorrectly then.
Looping with globes makes the system unstable(in incremental compilations).

All your rambling just proves that you are not well informed or don't care about quality.

I'll give you a simple example because it will take me days and turn me crazy to explain you everything that's wrong in your statements.

When you search for a system library in CMake, let's say OpenSSL:
```
find_package(OpenSSL REQUIRED)
target_link_libraries(YourExecutable PRIVATE OpenSSL::SSL)
```
Besides adding the correct linking, include paths, maybe check for compiler support for features used in the headers(if the CMake target used "target_compile_features") before starting to compile a few hours and hitting an error at the first source file that actually includes the header... it will add an explicit dependency on the required OpenSSL headers, thus, when you/your system administrator/your automatic security updates update that header file, running "cmake --build"(Makefile, Ninja, etc...), it will automatically detect the change and recompile only the source/targets that depend on that specific modified header, to make sure your incremental compilation is always 100% stable and you don't get some weird behavior at runtime because a struct changed in that header and the memory layout is different now.

When was the last time you've seen somebody add explicit dependencies in Makefiles, on system headers(not just include paths), so that the incremental compilation is 100% stable all the time - exactly, never, we are not tools, we cannot always track that.

You write absolutely garbage Makefiles with loops over your own source files(and only over your own damn local dependencies, making the build unreliable) and think that's better?