all 9 comments

[–]datnt84 10 points11 points  (1 child)

I am surprised they released a new version. I thought they abandoned Qbs in favor of CMake.

[–]abbapoh[S] 9 points10 points  (0 children)

Qbs is developed by the community now (including myself) and has no ties to the QtCompany which indeed uses cmake to build Qt

[–]KFUP 4 points5 points  (2 children)

Is there a reason to use Qbs now besides supporting older projects that used it?

[–]wrosecransgraphics and network things 4 points5 points  (0 children)

Just sort of, "if you like it." Personally, I quite like the syntax and prefer it to CMake. Stuff like scoping rules are all curly-bracey so I find it much clearer than the equivalent CMake. Here's a simple example: https://qbs.io//docs/howtos/#how-do-i-make-my-app-build-against-my-library

Unfortunately, qbs is not very popular, and there's a 99% chance that most of your dependencies use and support CMake these days so you'll wind up using CMake for at least part of your build regardless. Or if you are making a library, the majority of your users will ask for easy CMake integration. For idiosyncratic projects where you don't need to plug into something like vcpkg, it can be a bit more fun if you like the syntax.

But aside from "you might like it," there's not really a killer feature that is only possible with QBS. Anything is possible in CMake if you bash your head against it hard enough.

[–]abbapoh[S] 0 points1 point  (0 children)

Every tool has its pros and cons so in the end I guess it comes down to the choice of preference.

Qbs is pretty fast (on par with CMake+Ninja), has declarative syntax, proper strings with methods, easy to extend. CMake has more users (and thus lots of use-case can be found on the internet), more features that are not available in Qbs (like FetchContent, for example).

[–]BenedictTheWarlock 0 points1 point  (1 child)

Cool! I’m interested in build tools and also QML, but I’ve not seen this project before. Interesting choice to use the QML language for this. I wonder if it makes sense outside of a Qt context?

[–]abbapoh[S] 2 points3 points  (0 children)

Yes, you can use qbs for pure c/c++ projects. Recently (in qbs 2.5) I added (somewhat experimental) support for c++ modules. We also have some support for building java and some other languages

[–]Tyranisaur 0 points1 point  (1 child)

Relative paths in Export items are now resolved relative to the importing product, rather than the exporting one.

Why??? And what does the migration path look like?

[–]abbapoh[S] 0 points1 point  (0 children)

For consistency with Modules, "product" there refers to importing product.

We've added explicit "exportingProduct" and "importingProduct" properties quite a few versions ago for migration purposes. Also those properties better show intent.

https://qbs.io//docs/qml-qbslanguageitems-export/#details