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.mart...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
