QBS is deprecated: swich back to CMake

[Cogitri]

Today Qt officially announced that they're going to deprecate QBS in favour of CMake:

https://blog.qt.io/blog/2018/10/29/deprecation-of-qbs/

Packaging of MellowPlayer has been rather difficult with QBS, some distros (e.g. Void Linux) won't update to any MellowPlayer releases with QBS.

[ColinDuquesnoy]

What a sad news 😞I really think qbs is much better build system than cmake, at least from a developer point of view.

I guess we'll get back to CMake for next minor release. This is a lots of work as this change will impact CI and packages...

[ZeroDot1]

This is really very sad news, QBS worked very well with Arch Linux and was also a big relief for older computers, because the CPU was not so heavily loaded during compilation.

@ColinDuquesnoy I find it very sad, I am sorry that you have extra work again.

[Cogitri]

I really think qbs is much better build system than cmake, at least from a developer point of view.

Hum, maybe from a dev point of view it's nice, but for packagers it's hell :)
Thanks for looking into CMake again!

[ColinDuquesnoy]

Hum, maybe from a dev point of view it's nice, but for packagers it's hell :)

Out of curiosity, what issues did you faced when packaging MellowPlayer? I've ported rpm/deb/PKGBUILD packages from CMake to qbs and I don't remember it was a hell...

[Cogitri]

Out of curiosity, what issues did you faced when packaging MellowPlayer? I've ported rpm/deb/PKGBUILD packages from CMake to qbs and I don't remember it was a hell...

• It's yet another build system (that isn't perse bad, but already annoying)
• It hardcodes values
• QBS itself does its best to not cross compile sucessfully
• If you do get it to cross compile eventually it won't cross compile applications out of the box because instead of using the env variable almost EVERY BUILDSYSTEM EVER uses it uses some funny configuration thingie

[FuchtelJockel]

• It's yet another build system (that isn't perse bad, but already annoying)
• It hardcodes values
• QBS itself does its best to not cross compile sucessfully
• If you do get it to cross compile eventually it won't cross compile applications out of the box because instead of using the env variable almost EVERY BUILDSYSTEM EVER uses it uses some funny configuration thingie

+

• It doesn't work with flatpak unless you patch it.

[Cogitri]

It just simply doesn't work well (or at all) if you do anything slightly non-standard.

[ColinDuquesnoy]

@Cogitri I think it's a matter of perspective. If you expect qbs to work the same as legacy build systems you will be disappointed and maybe frustrated. When used correctly (work with toolchain configuration and profiles) you can get it to cross compile very well. I'd say my experience in cross-compiling some of my private projects was much smoother with qbs than with cmake.

qbs, as with any other tools, has it inconvenients (not enough documentation, no good system to discover system dependencies), it certainly needs to mature more to be complete and work well in corner cases or with new tools such as flatpak.

qbs is a modern build system and going back to cmake feels like going back to cvs/subversion when git is available (no native support for precompiled headers, no way to run tests automatically after a sucessfull build, no parallel builds by default, slow as hell,...).

Anyway it's not worth discussing this further, qbs is deprecated and I will switch back to cmake because it has the best support in IDE (otherwise I may have gone to meson).

[Cogitri]

otherwise I may have gone to meson

If you wanted to I can make a meson port :)

[ColinDuquesnoy]

If you wanted to I can make a meson port :)

That's very kind of you, thank you. I wouldn't be against including a meson port of the cmake build scripts but I probably wouldn't use them myself.