ByteBulletin

[tooling] · · 1 min read

QtScript Gets a Qt 6 Port, Bridging a Decade-Old Scripting Gap

A new open-source project patches the legacy QtScript engine to run on modern Qt 6 environments, preserving compatibility for developers relying on the embedded JavaScript runtime.

By ByteBulletin Editors · Editorial Team

[tooling]

For years, QtScript has been a relic of the Qt 5 era, largely abandoned as the framework moved forward. However, a new GitHub project, qtscript-qt6, is breathing new life into the technology by providing the necessary patches to build the QtScript core module and the ScriptTools debugger with Qt 6 on both Windows (x64/MSVC) and Linux (x64/GCC).

The project targets Qt 6.8 LTS as its baseline, with continuous integration also covering the latest 6.11.x releases. Rather than vendoring the source code directly, the build script clones KDE's QtScript 5.15.19 revision, copies the Qt 6 CMake entry point, and applies a series of ordered patches. This approach ensures that the resulting installation mirrors the familiar Qt 5 layout, with headers under include/QtScript and CMake packages under lib/cmake/Qt6Script, minimizing friction for existing projects.

One of the key technical challenges in porting legacy code to modern Qt is handling deprecated APIs. The project addresses this by implementing legacy QRegExp signatures using Qt 6's QRegularExpression. This compatibility layer supports regular-expression, wildcard, fixed-string, capture, and replacement behaviors, and is compiled in by default but can be disabled with the -DSCRIPT_QREGEXP=OFF flag. Developers can find a detailed inventory of these changes in the repository's docs/PORTING.md.

It is worth noting that the project was developed with AI assistance under human planning and review, with every change verified by continuous integration. Despite these modernizations, the underlying engine remains a legacy 2011 JavaScriptCore snapshot. As the maintainers explicitly warn, QtScript is not a security sandbox and should only be used to run trusted scripts. For those interested in a more modernized approach, the repository also points to a work-in-progress branch that explores ditching JSC in favor of QuickJS-NG.

SHARE

← All stories