Been thinking about the "why" this has deprecation has happened: -CMake has large user base -> As a result, CMake has a large corporate user base --> As a result, a lot of Qt Commercial users use CMake
The Qt Company only asked commercial users their opinion, so the results are garbage. CMake did not win on technical merit, even Qt Company employees admit that. Imagine if, in the early days of Qt, Qt itself was announced as deprecated simply because more [corporate] users used Gtk/C? Where would we be today? Qbs hasn't seen much community contribution because it's state-of-the-art software that's functional. It's difficult to dive into and add features to state-of-the-art software simply because as non-authors of the code we don't have the vision and designs/plans for the project and where it's going (in the macro sense), let alone familiarity with the heart of the code base. Maintaining compilers/flags, fixing bugs, and adding incremental features, though? That can easily be achieved by the community... indefinitely. There haven't been community contributions to maintenance/etc of Qbs for one simple reason: there didn't need to be, Qt Company did it. Community software progresses forward from independent developers "scratching their own itch". You scratched our Qbs itch for us, then point out nobody contributes to Qbs. Why would we when it works fine (not only fine, but GOOD)? Qbs adoption never took off because you never defaulted to it, never took it out of "experimental" state. I was eyeing it for years, agreeing it was superior, ready and waiting to start using it as soon as Qt defaulted to it... and it appears many others were doing the same. Was Qbs not defaulted to because Qt Company was waiting for more users to start using it, while the users didn't use it because Qt Company never defaulted to it? LoL, cyclic dependency <3: You never gave Qbs a chance. I think in the long run a community-maintained Qbs could outgrow CMake, simply because Qbs is designed better (some CMake devs would change camps). [Incrementally] Copying what CMake does, but implementing with a better design, still adds value even though it partially reinvents the wheel. Take for example LibClang and all the [easily used] functionality it adds on top of GCC. Better design = more useful... even though Clang had to "reinvent the wheel". And besides, Qbs is already functioning, should have defaulted to it and the corporate users would have largely accepted it. Corporate users are usually the last ones to dive in and adopt EXPERIMENTAL software. And hell, if I was a corporate user right about now I'd place significantly less stock in any of Qt Company's "experimental" software... because it might just up and disappear at a whim. d3fault p.s. I don't care if qtbase uses CMake/QMake etc, since I don't maintain those projects. But for my own projects, I really want[ed] to use Qbs. The way you organized libs and apps and all that in Qbs was downright pleasant to navigate. _______________________________________________ Qbs mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qbs
