Very, very, very often the command “Build release container for the application” in the VSCode Torizoncore extension does not detect new code changes in C++ or QML. Most of the time, if I manually run ‘make clean’ in the build container shell, the changes will be included, but not all the time. Considering how long it takes to deploy new code to the target device, this is a major time drain on development.
I’ve run ‘make clean’ and added this obviously uncompilable code to a cpp file:
void CANTransreceiver::processThrottleInfo(QByteArray byteData)
uint16_t throttle = byteData << 8 | byteData;
qDebug() << "Got " << (uint8_t)byteData << ", " << (uint8_t)byteData <<"\n";
//qDebug()<<"Emitting throttle : "<<throttle<<"\n";
yet i’m looking at:
[01-04 22:27:02.067] —> Using cache
[01-04 22:27:02.068] —> de17ca14804c
[01-04 22:27:02.068] Step 9/9 : CMD /App/App
[01-04 22:27:02.068] —> Using cache
[01-04 22:27:02.068] —> 9d43406d0faa
[01-04 22:27:02.133] Successfully built 9d43406d0faa
[01-04 22:27:02.139] Successfully tagged app_arm32v7-qt5-wayland-no-ssh_bullseye_release_4a1f6295-4113-4fc8-838e-ec856811283a:latest
[01-04 22:27:02.156] Image has been built successfully.
Obviously the caching is the problem, but this is ridiculous. The IDE’s build should capture changes made in the IDE.
I’ve restarted VSCode, switched between build and release configurations, cleaned and built (failed), triple checked that the file has changed on disk. Why does “build release” cling to an old version of source??? It even runs a whole ‘qmake’ in the terminal, so there must be an entire shadow directory somewhere in this docker-lypse.
I can replicate something that looks like this behaviour by running ‘make install’ from the build docker. ‘make install’ succeeds even if ‘make all’ errors out. Since this make file looks autogenerated, I guess it’s fair to say this is either a bug in the extension, or I’m misusing it somehow. Why would this happen?
… and it looks like ‘rm -rf appconfig_0/work’ actually cleaned up enough to get a new binary.
… or it did until now… how does:
void CANTransreceiver::processThrottleInfo(QByteArray byteData)
int throttle = byteData<<8 | byteData;
//qDebug() << "Got " << (uint8_t)byteData << ", " << (uint8_t)byteData <<"\n";
qDebug()<<"Emitting throttle : "<<throttle<<"\n";
>>>>>>>>>>>>>>>>>>>>>>>>>yielding the build output:
make: *** [Makefile:418: cantransreceiver.o] Error 1
make: Leaving directory '/workspaces/founders/tarform/Communication'
make: *** [Makefile:76: sub-Communication-make_first] Error 2
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>after a $make clean and :
torizon@docker-desktop:/workspaces/founders$ ls appconfig_0/work/
ls: cannot access 'appconfig_0/work/': No such file or directory
/usr/lib/qt5/bin/qmake -install qinstall -exe App /workspaces/founders/tarform/appconfig_0/work/App/App
make: Leaving directory '/workspaces/founders/tarform/App'
[01-04 23:13:54.270] Step 9/9 : CMD /App/App
[01-04 23:13:54.271] ---> Using cache
[01-04 23:13:54.271] ---> 556cbf9d9ffe
[01-04 23:13:54.315] Successfully built 556cbf9d9ffe
[01-04 23:13:54.320] Successfully tagged app_arm32v7-qt5-wayland-no-ssh_bullseye_release_4a1f6295-4113-4fc8-838e-ec856811283a:latest
[01-04 23:13:54.339] Image has been built successfully.
I’m checking in with our IDE team to see if they have an idea regarding the behavior you’re seeing here. But let me ask some questions to get a better idea of the issue here.
- First of all what version of the IDE extensions are you using? (Stable or Early Access)
- You specifically mentioned the release configuration in your issue. Have you ever observed this issue in the debug configuration? Or is it only in the release configuration for some reason.
I have a theory/suspicion of what might be going on here. So the caching that you noticed is a Docker feature rather than an IDE one. Docker should pick up that something has changed and not cache everything. But in this case it seems as if it’s convinced nothing has changed.
I wonder what happens if you force a rebuild of the application binary with the
build_release task first. Perhaps this would make Docker see the change. Then again the
Build release container for the application should also re-build the application if the source changes so this is more of a work-around then a fix.
Again I’ll check with our IDE team, but please answer my above questions so that we have additional info.
Thanks for the reply,
I’m using the 1.3.0 stable version of the extension.
I’m not a pro regarding vscode’s build commands, but I have played extensively with “ctrl-shift-b”, which I believe should run either the
build_debug tasks, after a manual
make clean. All build errors from my previous posts were started with “ctrl-shift-b”.
The output I posted is showing a difference between that and the “F1->Build release container” command.
To this point here are results from a debug build:
communicationhandler.cpp:45:5: error: exponent has no digits
45 | 66666666666emit speedChanged(m_nSpeed);
make: *** [Makefile:423: communicationhandler.o] Error 1
////[f1-> build debug container]
[01-08 18:26:53.516] Step 10/10 : CMD stdbuf -oL -eL gdbserver 0.0.0.0:6502 /App/App
[01-08 18:26:53.517] ---> Using cache
[01-08 18:26:53.517] ---> a30e2162789f
[01-08 18:26:53.585] Successfully built a30e2162789f
[01-08 18:26:53.590] Successfully tagged app_arm32v7-qt5-wayland-no-ssh_bullseye_debug_4a1f6295-4113-4fc8-838e-ec856811283a:latest
[01-08 18:26:53.608] Image has been built successfully.
///The filesystem as seen by the build / extension container:
torizon@docker-desktop:/workspaces/founders/tarform$ grep -n 666666 Communication/communicationhandler.cpp
45: 66666666666emit speedChanged(m_nSpeed);
FOUND IT! Not Torizons fault per se. I inherited this build from anther engineer, so I’m still discovering the way it’s set up.
The problem has to do with an intermediate static library that the code gets built into. Most of my clients code base gets built into static libraries first, before a final binary. I’m not mad at the extension via Docker and qmake (etc) for building with old libs. RESOLVED.
BTW, the solution is to add your libraries to the QMAKE_CLEAN variable in the
That makes sense. Also explains as to why the code changes were being inconsistently picked up by the IDE.
Anyways thank you for sharing your findings here, I’m sure it will be of use to someone else in the future.