[Qbs] Donation to QBS developers/maintainers/contributes

Oswald Buddenhagen oswald.buddenhagen at gmx.de
Wed May 15 11:38:25 CEST 2019

On Tue, May 14, 2019 at 04:17:41PM +0200, Иван Комиссаров wrote:
> Qbs itself has a huge dependency on a QtCore, but some stuff is
> present in standard library and can be easily changed to that (we
> still have enourmous amount of places where qlist is used instead of a
> qvector/std::vector and used inefficient);
yes, getting rid of qt containers is easy. only the qtcreator plugin
would still need them (and it's a good question where to draw the lines
to not introduce unnecessary conversion inefficiencies).

qstring is a lot harder ... 

> others are trickier but can be bootstrapped (like qfile) if needed.
bootstrapping qt classes is counterproductive (you notice latest when
you link libqbs into qtcreator) and laborious (you notice latest when
you get to qprocess or another class that *needs* full qobject/moc and
the qt event loop to operate sensibly).

as of now, there is no reasonable alternative to pulling in random
external dependencies, possibly boost (fwiw, the relevant c++ stdlib
projects are apparently dormant).

> But what about QtScript's dependency on the QtCore/other libs? My
> point was that it may depend on the qtlibs more than Qbs does and the
> biggest job is there, not in Qbs core.
for the js engine, a bare JSC was considered.
hmm, come to think of it, the js engine might not be the only part from
webkit (or webengine) that makes sense to build upon ...

jake had started that "qt-free qbs" project (he got as far as
eliminating (most) use of qt containers), but it was snuffed out because
it was unrealistic and counterproductive at that time. even now, no
patches in that direction will be accepted unless a coherent final
picture and a credible committment to further maintenance is presented.

More information about the Qbs mailing list