[Development] Future of QBS

[Sergio Martins]

Hi,


At the QtCS it was mentioned that maybe qbs could use JavaScriptCore and 
std:: types,
at first I thought this was for making it easy for qbs to be a non-Qt 
project, but then I realized it was for boot-strapping purposes.

I don't know if you have a vision, but given that most other build 
systems suck you can't miss this opportunity for making a great build 
system for everyone, not only for Qt.

Please make something we can easily detach from the qt-project in 10 
years and have it's own ecosystem.

The qt-project isn't in the business of maintaining JavaScript engines 
or build systems, this model works now because TQC has manpower, but if 
something bad happens in 10 years, then it will be a maintenance burden 
and rot.

So IMHO, no updating QtScript with newer JavaScriptCore and no adapting 
the QML/V4 engine, go straight for pure JavaScriptCore/JerryScript and 
no linking to Qt.

Sincerely, I think you have a great product but are aiming too low. A 
few days ago I had to figure out if I was on a Rel,RelWithDebInfo CMake 
build and ended up having to manipulate strings with TOUPPER, since it's 
case sensitive. It's an horrible experience and syntax which 
declarative/QML solves.

IMHO the qt-project is not in a position to reject Qt building with qbs, 
simply because there's no other implementation, nobody is going to port 
Qt to CMake (if you disagree start a new thread). But what we can 
discuss is if we want to make qbs easier to maintain long-term.


P.S: This is my personal opinion, not of KDAB's (haven't discussed it 
internally) and definitely not of Kevin Funk (CMake guy ;))


Regards,
-- 
Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts