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,

8

Hey @Fractal

we take a look and it’s seems that this is the normal behavior from the Qt qt_add_qml_module CMakeLists.txt. But your complaint is fair. Depending on the size of the project and the machine, the development cycle could be slow. We had discussed this with our product management, and the use of native build, instead of the Docker emulation, was prioritized for this quarter. This should speed up the cycle, and leave the behavior more close as a default native Qt development.

As soon as we have it implemented on our templates, I will notify you.

9

Hi @Fractal we are sharing your pain :wink:

Our project has over 270 CPP files to build, and it takes 10 times longer to build this (~40 minutes) with the VSCode extension in comparison to 4 minutes with a native cross-compiler build (running in an Ubuntu VirtualBox). It takes the extension about 4 minutes just to perform all its container manipulations to run a debug session, without building anything ! (@matheus.tx can it not wait until after a successful build before deleting the containers on the device ?)

IIUC it is building inside a docker container, inside WSL using an emulator, operate through a bunch of scripts handled by VSCode. So this is no surprise.

On top of that, from time to time, it starts downloading new versions of libraries, which takes an age. Which, I should add, is quite the opposite of our requirements - which are to explicitly control all of the code which our medical application is using. At some point I will have to dig through the various layers of configuration files and scripting to figure out how to control this (see also this).

Whilst these new, fashionable tools are all very exciting to play with, they do not improve anything. In fact my experience so far is significantly worse in comparison with working in QtCreator. The debugger fails on occasion, and in some circumstances my only choice is to reboot Windows FTLOG.

Although the documentation claims that I should be free to concentrate on my code, the truth is quite the opposite. After making a change in my code to test something, it takes so long for the debug code to run, that I have almost forgotten what it was that I was trying. Then sometimes the debugger locks up, and I have to reboot everything.

Frankly, I don’t see containers as adding anything useful for our use-case. They were never designed for running a single application on an embedded device. They are not fit for the purpose. They (probably) impose a extra layer of security, but, imho, this adds significant complications to the code, which are more likely to lead to bugs. The Linux user privilege, which docker relies on, is probably sufficient.

We should be able to develop our application independently from any container. The container should be applied independently, only when the application is deployed, applying the privileges to the container that the application requires. The fact that an application needs to be changed in order to accommodate the container goes to show that the container is not a suitable tool.

Well, perhaps we are an edge case. I suppose not everybody has to provide full control over the system clock.

Sorry for the rant - I hope we can revert to bitbaking our OS from the base-level Torizon in the near future - I think that would suit our overall requirements better…

Tim

2 Likes
10

@matheus.tx: Thanks for the response.

Definitely! The Yocto days were much cleaner, faster and better all round, once you got to grips with the various recipes, etc. It was a steep learning curve, admittedly, but at least you were in control, and application development was a breeze compared to the current ecosystem. As Timo said, containers don’t really add anything useful, especially if you don’t require non-root users.

I’d love to be using Qt6 (Angstrom was only 5.9) and preferably X11, not Wayland. VNC is a requirement for us and we have to be able to start/stop and configure VNC at run-time, with passwords that can be changed. As I understand it, VNC with Wayland is a pile of ***** :slight_smile: .

1 Like