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

[oleid]

Thats not about being organized, it's about using 3rdparty sources without modifying them.


What's so bad about cmake, when properly used?

add_subdirectory(3rdparty/baz)

add_executable(foo main.c source1.c)

add_dependency(foo baz)

And that's about it.

[oleid]

Well it's a sad day when a simple one-liner sed or awk script is considered "reinventing the wheel" especially when you can easily copy & paste it.

As if it was one simple one-liner.... How about the following: create a git repo with the layout I proposed before and compile it via your makefile setup. I'll do the same for cmake and we'll let the people vote what's easier.

[Weasel]

Thats not about being organized, it's about using 3rdparty sources without modifying them.

Like I said, we're in a massive mess right now because of this convoluted "build system" mess in the first place. You may not want to modify the sources (well just their #include directives really), but you got to start at some point or else this mess will be here forever. Hence my rant.

I mean it's not the build system's fault itself but more like people who got used to the idea to drop their shitty headers in /usr/include or /usr/local/include and now don't want to modify their sources to organize them properly. They got used to it because of the build systems enabling it for them tho, so they have part of the blame.

What's so bad about cmake, when properly used?

add_subdirectory(3rdparty/baz)

add_executable(foo main.c source1.c)

add_dependency(foo baz)

And that's about it.

I don't know CMake that well, but here's things from your example and in general:

• You have to add every source file manually? You don't need globbing with makefiles btw, since you can call shell commands, a simple "find" piping does the trick.
• You need to install CMake. Yet another build dependency and system alteration. And remember: you also have to update it every once in a while. More burden, yay. (and there's plenty of build systems so even more garbage installed)
• In your case it's used sanely, but in most cases they are used to look for system-wide installed libraries. I hate this so much, you have no idea, and it's not just about build systems. First, the build environment must NOT match the runtime environment, that's the sanest way to know you can build apps that can be distributed.

Some things are ok to be installed "system-wide", like platform-specific bits. That's normal. Anything else = big fat no.

[Weasel]

As if it was one simple one-liner.... How about the following: create a git repo with the layout I proposed before and compile it via your makefile setup. I'll do the same for cmake and we'll let the people vote what's easier.

I don't really understand what has git to do with it. Obviously voting isn't gonna work, people usually vote for what they are familiar with. I'm sure users would at least vote for something that needs only a "make" rather than installing some build system and then running some configuration first before they can type make (depending on build system). Note that you can do the config in the make params itself if you want (or use the common env vars).

[brrrrttttt]

You know the funny thing is that a lot of the build systems require a lot of painful setup and "reinventing the wheel" (especially autotools). They're beyond convoluted and bloated (and CMake syntax is ABSOLUTELY horrible) so in fact they're even worse to "read" than a Makefile.

Some people really don't understand how powerful Makefiles actually are I guess. They're not more convoluted than build configs at all.

Totally agree. GNU make is more than sufficient, and much easier to deal with for a great many projects (and useful for much more than just building software!). CMake, autotools etc. are just Makefile generators anyway. :P And yes, the CMake DSL is truly horrid, just like autotools.

[oleid]

I mean it's not the build system's fault itself but more like people who got used to the idea to drop their shitty headers in /usr/include or /usr/local/include and now don't want to modify their sources to organize them properly.

I'm not talking about installing stuff to /usr/whatever. Having several include roots "per dependency" makes sense, even if you're never going to install anything. It abstracts away your source code layout.

You have to add every source file manually? You don't need globbing with makefiles btw, since you can call shell commands, a simple "find" piping does the trick.

Sure you can do globbing, but it's considered bad style. Imagine you want different targets in the same directory, i.e. some "add-on" feature, you don't need in every case.

You need to install CMake. Yet another build dependency and system alteration. And remember: you also have to update it every once in a while. More burden, yay. (and there's plenty of build systems so even more garbage installed)

Cmake is hardly a dependency hog. You only need some elder v3.x version and you're good. No upgrading, besides the usual distro bugfixes needed. Being bound to shell, gnu tools etc is more of a burden. Maybe you need to distribute your source to Windows or *BSD? I know gnu stuff is available for both platforms, and in the case of *BSD, awk and friends are already available, however, they work differently and you need to install the gnu variants to stay compatible.

Please note, that cmake has multiple backends. GNU Make is only one of them. There are also ninja and nmake (for microsoft stuff). Hence, it can use what's available on your target platform.

In your case it's used sanely, but in most cases they are used to look for system-wide installed libraries.

If it's your project, you can do whatever you want. Even bundling the dependencies, so that you don't have to look for system wide libs. But that's hardly the fault of the build system. You'd have to deal with it, too, if you wanted to use system's libs from your makefile project.


In most cases, when people say cmake looks ugly, they have seen examples out in the wild that make grown-ups cry. But the same can be said about autoconf and even makefiles. Cmake before 3.0 was quite ugly, the new stuff is quite nice, when being used idiomatically.

https://www.youtube.com/watch?v=HPMvU64RUTY

[Weasel]

I'm not talking about installing stuff to /usr/whatever. Having several include roots "per dependency" makes sense, even if you're never going to install anything. It abstracts away your source code layout.

Why should it be abstracted? Having it organized is good to me. Obviously if you mean that you want to build a static library dependency then it surely needs its own makefile and similar layout (so no abstraction needed).

Maybe it's a matter of preference but I dislike this "abstractions" of #including header files as if they were all bundled in one freaking directory. I don't know who the fuck came up with the original idea but it's just stupid. Even standard library sucks: you do #include <stdio.h> or #include <limits.h>. It should be #include <std/io.h> and #include <std/limits.h>. I have OCD about this and I can't stand "stuff bunched together in one directory" when it doesn't belong there.

Sure you can do globbing, but it's considered bad style. Imagine you want different targets in the same directory, i.e. some "add-on" feature, you don't need in every case.

Well you can just #ifdef the code so that it outputs nothing in the object file...?

Cmake is hardly a dependency hog. You only need some elder v3.x version and you're good. No upgrading, besides the usual distro bugfixes needed. Being bound to shell, gnu tools etc is more of a burden. Maybe you need to distribute your source to Windows or *BSD? I know gnu stuff is available for both platforms, and in the case of *BSD, awk and friends are already available, however, they work differently and you need to install the gnu variants to stay compatible.

Please note, that cmake has multiple backends. GNU Make is only one of them. There are also ninja and nmake (for microsoft stuff). Hence, it can use what's available on your target platform.

Fair point. I assumed CMake relies on GNU Make anyway, and I'm so used to the unix shell build process that I forgot there's other stuff like Visual Studio and so on.

But if it doesn't rely on it then I guess it's a point if you want "true" cross-platform support without installing cygwin or MSYS or anything. This doesn't apply to autotools though, since that one kind of depends on an unix environment.

[aht0]

What's so bad in installing stuff under /usr/whatever like /usr/local? Eludes me..

[brrrrttttt]

What's so bad in installing stuff under /usr/whatever like /usr/local? Eludes me..

Nothing, that is where stuff you compile on the machine is supposed to go, see https://en.wikipedia.org/wiki/Filesy...archy_Standard .

[Weasel]

What's so bad in installing stuff under /usr/whatever like /usr/local? Eludes me..

Facepalm. Multiple points of failure.

Bundle everything in 1 directory: you can literally just copy it to another machine and it would build in the exact same way, assuming same compiler (which SHOULD also be able to be copied!). Reproducible.

/usr/whatever may have different header (older, full of bugs) on another machine, then you compile and you have shitty bugs and waste everyone's time tracking down a PIECE OF SHIT that shouldn't exist in the first place.

Or... you know... it fails to fucking compile with retarded error messages, as is so fucking obvious from everywhere on the internet; just look at all the compilation woes even on stackoverflow (yes, really, a site for programmers) and ALL OF THEM are due to DEPENDENCIES and CRAP THAT THE PROJECT ASSUMES IS "INSTALLED".

Can't be simpler than download (or copy) and then type "make" with perhaps a config beforehand (like the kernel). That's sane, what we have is NOT. If it was sane we'd have literally zero inquiries about "why doesn't this compile? why I get this error?!??"