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. _______________________________________________ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs