Torizon IDE Extension not fit for serious Qt/QML development?

Technical Support
,
1

Ok, here’s the problem:

I have a Colibri IMX6DL target, running Torizon OS 7.x. My development machine is running Linux and I have installed VS Code (1.116.0) and Docker (28.5.2) and the IDE extension (3.4.2). Hello-world, C++/QT, Python, all build and debug and deploy fine. BUT, and it’s a BIG BUT, VS Code insists on rebuilding all of the QML each and every time I do anything, like F5/Debug, deploy, run the ‘open-in-qt-creator’ task, anything, really.

For a simple project with one or two QML files, this is a minor irritant but unfortunately, with a serious project containing many C/C++ files and headers and a large resource file of images, fonts and dozens of QML files, this becomes an impossible ecosystem to use for development. If I want to make a small change such as to change the background colour of a QML rectangle or the width of a frame’s border, or change a QML string, I have to wait nearly an hour for the project to completely rebuild the resource file and recompile the entire suite of QML files. It’s unacceptable.

For example, if I build the project, test it on the target and stop it cleanly, then make no changes at all and F5 the project again, it rebuilds it again as though every QML file has been touched and changed. Why? It doesn’t appear to rebuild any of the C/C++ files.

So, either the extension and/or VS Code is broken, or I am missing something. I already interacted multiple times with the chatbot here and got sent down a couple of rabbit-holes to no avail (it seems to think that blogs and resources from 5 years ago are somehow relevant - they are not). Help appreciated, please!

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

I understand your frustration with the unnecessary rebuilds in Qt/QML projects using the Torizon IDE Extension. This is indeed a significant issue for larger projects with extensive QML resources.

Understanding the Build Process

The Torizon IDE Extension uses containerized builds where each debug session triggers a complete container rebuild(1). This behavior is documented as creating a “debug container” with configurations that enable remote debugging via SSH(1).

The documentation acknowledges this limitation, stating: “It may take a while to build the container image the first time you run the debug process. The time depends on the size of your project, the speed of your network connection and the target/development CPU configuration”(1).

Potential Solutions and Workarounds

1. Check Your Project Structure

Ensure your project follows the recommended structure documented in the workspace reference(2). The extension expects specific file organization for optimal build caching.

2. Review Docker Build Context

The issue might be related to how Docker handles the build context. Large resource files and QML collections can invalidate Docker’s layer caching, forcing complete rebuilds.

3. Consider Release Container Builds

For testing without debugging, you might use release container builds instead of debug containers. The documentation mentions that debug containers include additional configurations that may impact build efficiency(1).

4. Investigate Build Dependencies

Check your .conf/deps.json file(2) and ensure build dependencies are properly configured to avoid unnecessary rebuilds.

Recommended Actions

  1. Enable detailed build logging to identify what’s triggering the rebuilds
  2. Review your Dockerfile and build configuration for unnecessary COPY operations of large resource files
  3. Consider splitting large resource files into smaller, more manageable chunks
  4. Use the production build workflow(1) for testing iterations where debugging isn’t required

The behavior you’re experiencing suggests the extension may not be optimally handling incremental builds for Qt/QML projects with large resource files. This appears to be a limitation of the current containerized build approach rather than a configuration issue on your end.

You may find relevant discussions on the Toradex Community by searching for “Qt build performance” or “incremental builds”.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Greetings @Fractal,

Let me bring this up with our extension team and see what we can uncover.

Best Regards,
Jeremias

4

Hey @Fractal ,

welcome to our community.

Did you already tried to use the QML as assets, loaded at runtime, instead of resources?

BR,

5

Thanks for getting back to me guys.

Some more information for you: I think it’s something I am doing wrong or have misconfigured somewhere, because this morning I made a brand new Torizon C++/Qt project (the example from the template, the one which spins up Weston and displays a single window with the Torizon logo and the Opacity and Scale Animators). I F5’d it once and closed the debug session. Then I F5’d it again (no changes) and it did not rebuild it all again, so it is building as expected. Then I made a small change to “main.qml” - I changed the duration of one of the Animators. When I F5’d again, only “main.qml” was recompiled (and the .rcc of course), so it is building as expected.

So for my main project I must have broken something; what could I be doing wrong?

6

I attach a small Qt/QML project demonstrating the problem. I pretty much dumped the whole project in to a zip file. I have redacted my torizon password in .vscode/settings.json - if you want to try building and running this, you’ll need to sort out your default device’s connection details but you already know that.

It’s only little: a main.cpp, a header and source for a QObject which does some stuff, a main.qml and one .png file.

The QObject has a Q_INVOKABLE public function and main.cpp registers the QObject to the root context of the QML engine, which allows the QML to access the C++ public function. It does this periodically using a Timer. The data given back to the calling QML by the QObject’s function is displayed in a Label. This demonstrates in a basic way the sorts of things a proper application often needs to do.

My target is a Colibri imx6DL. My development system is in Ubuntu 24.4.

This project builds just fine and runs a treat, but VSCode insists on rebuilding the .rcc each time, despite no changes having been made between builds. Why? Thanks in advance if you find anything.

Demo.zip (187.6 KB)

7

@Fractal thanks to share. I will check and will get back to you.

BR,