How to recreate a project using the newest xonsh driven plugin

Technical Support
, , , ,
1

I have a C++ Docker container project that was mothballed about 15 months ago, and while I can compile it with the existing plugin (powershell), I would like to bring it up to the latest version using xonsh. I used it with a Makefile.
I have used it with a python project, but with C++ it must be compiled into an executable then put into the container image. I am trying to recreate the image so I can put it in a Gitlab Container repository. Before, I have just used a HelloWorld example and then just added my code to it and changed the names. But because the default is cmake, I am unsure how to get that working. I couldn’t find a .xsh file that dealt with the setup of that. But cmake is complaining it is “not the same as the original…” I still have my Makefile and since it was working that way, I maybe should just do that? Not really sure how to proceed at this point.

Any help would be welcome.
Steve

Thanks,
Evets

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

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

Hello Steve,

Thank you for your question! Migrating your C++ Docker container project to the latest Torizon IDE Extension with xonsh support can indeed be a bit confusing, especially with the transition to CMake as the default build system.

Here’s how you can proceed:

1. Makefile Approach (Recommended for You)

Since you already have a working Makefile and the project built correctly before, you can continue using your Makefile with the latest Torizon IDE Extension. The extension does support Makefile-based builds, and this will let you avoid unnecessary migration complexity.

To set this up:

  • Place your Makefile at the root of your project folder.
  • Ensure your source files and Makefile are referenced correctly in your project’s workspace and container build files.
  • If you need to include additional external libraries, add them to the LDFLAGS variable in your Makefile:
LDFLAGS := -l<library-1> -l<library-2>

More on Makefile usage and adding dependencies

2. CMake Approach (Optional/New Projects)

If you’d like to migrate to CMake, you need to:

  • Make sure the SDK includes CMake by adding the following line to your build/conf/local.conf:

    TOOLCHAIN_HOST_TASK:append = " nativesdk-cmake"

  • Create a CMakeLists.txt in your project directory as shown below:

    cmake_minimum_required(VERSION 3.21)
project(MyProject VERSION 1.0 LANGUAGES CXX)
add_executable(my_project main.cpp)
# Add additional sources or link libraries as needed

  • Configure your .devcontainer or workspace files to use your new CMake build system.
    Full CMake example and configuration guide

3. Image Creation and Pushing to GitLab

Once successfully built (using either Makefile or CMake), you can create the Docker image using the standard workflow in your Torizon workspace. After building, tag and push your image to your GitLab Container Registry as usual.

4. Troubleshooting and Permissions

If you face permission or compilation errors with the new IDE/container setup, double-check the following:

Summary & Recommendation

Since your project already works with a Makefile, I recommend you stick with that path for minimal disruption. The Torizon IDE Extension intends to support both approaches, so you don’t have to convert everything to CMake unless you want to modernize your build setup.

Let me know if you need a detailed step-by-step for setting up either workflow, or run into any trouble with the container build!

Best regards,
Toradex AI Assistant

3

What about using xonsh mechanism instead of the powershell? All the tasks.json and other files are completely different when compared to each other.

4

Hi @EvetsMostel1

Have you tried running the try-update-template task? That basically does a git merge to bring in the latest template change while maintaining yours.

That’s obviously not a perfect fix and you may need to do some cleanups due to patch conflicts but it may get you close.

The alternative would be to start a new project and just migrate your sources into that. Depending on the scope of your changes, that may be easiest.

Drew

5

@drew.tx
Hi Drew,
No, didn’t see that. But what I did was create a new empty C++ project, then just moved my code into it. The biggest issue was just keeping the makefile version instead of going to a cmake version. Once that was done, it builds up to the point of the loader, where in my old version it doesn’t have any trouble finding the libgpiod, but is unable to using the xonsh version. the tasks.json are really different, but since the makefiles are EXACTLY the same now, I don’t see how it can’t find it, especially since it’s in the same machine running the same code. I remember I had some issues with that, but since the makefile is the same, unless it is using a different toolset, I can’t think of what it would be.
I changed my torizonPackages.json file to the following:
{
“deps”: [
“libgpiod”,
“can-utils”,
“iproute2”
],
“devDeps”: [
“libgpiod-dev”
],
“buildDeps”: [
“libgpiod2”,
“can-utils”,
“iproute2”
],
“prodRuntimeDeps”: [
“libgpiod2”,
“can-utils”,
“iproute2”
],
“devRuntimeDeps”: [
“libgpiod-dev”
]
}
It does look like it puts that in the DockerFile.sdk as well as the DockerFile.debug, but it still can’t find the gpiod library when linking.

Any Help would be appreciated.

Steve

6

You still have “libgpiod” in “deps” rather than libgpiod2. Not sure if that’s related.

Have you compared your files against our sample?

7

Well, the solution was to modify the packages to this:
{
“deps”: [
“libgpiod-dev”,
“can-utils”,
“iproute2”
],
“devDeps”: [
“libgpiod-dev”
],
“buildDeps”: [
“libgpiod-dev”,
“can-utils”,
“iproute2”
],
“prodRuntimeDeps”: [
“libgpiod-dev”,
“can-utils”,
“iproute2”
],
“devRuntimeDeps”: [
“libgpiod-dev”
]
}

1 Like
8

So, I can compile now, but I get exceptions coming up in Boost logging, which is the only part of Boost that we use. Everything seems to compile fine, and I can get into debugging, but as soon as I encounter some Boost thing, it’s like it isn’t really there, and will cause an exception. I believe we are set to use C++ v17, but Boost has been testing with tons of versions, including v17 with no issues. And it is in the build process, as the older ps version, doesn’t have this issue. I tried to put in the makefile a printout that would show the version being used, but it didn’t seem to work.

Steve

9

Let me know if you can make any headway on this Boost issue. Any more info like build errors and such would be helpful.

Drew

10

It may be just an issue with linking a library compiled with a different version of compiler. But that would mean that my older ps style version must be using the same version of compiler or at least a compatible one.

11

@drew.tx
Hi Drew,
So, I think the problem is that when it links, it uses LD for the linker, instead of g++. That is the only difference I can see. I can’t get it to link with LD from the sdk container. It is setting c++ to v17 in both cases when compiling. If I change the order of the boost files (things that others have suggested as well as boost), I can get things to change, but no matter what I do, there is always something it won’t link to. Since my Makefile is the same in the that regard, I don’t see where in the new stuff it knows how to substitute the LD as the program to use. Any help pointing that out would be appreciated. I am pretty sure that’s my last issue. For GNU g++, it says to use the g++ as the linker. Maybe have something to do with the c++ name mangling, which would explain why I can’t link to the boost library (perhaps).

Steve

12

Hi @EvetsMostel1

How are you concluding that it is using ld instead of g++ for the link step? I just created a new project from the “C/C++ Makefile Console Application” template and the Makefile contains the following as the link steps:

	$(CC) $(CCFLAGS) -o $@ $(OBJ) $(LDFLAGS)
	$(CC) $(CCFLAGS) $(DBGFLAGS) $(OBJ_DEBUG) -o $@ $(LDFLAGS)

In this case it is using the CC variable which is defined as g++.

Are you using that template or something else?

13

@drew.tx
In the errors, it was mentioning the loader (ld) so I thought maybe it was it. However, out of desperation, I just recopied original boost files from the older directory back into the new folder and the whole problem went away. Not sure why that worked, but it did.

The only problem i have now is that when it going into debugging, it is asking for a password, but it isn’t that because I gave it the password and it says access is denied. It is using the newer debug setup in the dockerfile.debug:

RUN mkdir /var/run/sshd &&
sed ‘s@session\srequired\spam_loginuid.so@session optional pam_loginuid.so@g’
-i /etc/pam.d/sshd &&
if test $SSHUSERNAME != root ;
then mkdir -p /home/$SSHUSERNAME/.ssh ;
else mkdir -p /root/.ssh ; fi &&
echo “PermitUserEnvironment yes” >> /etc/ssh/sshd_config &&
echo “PermitRootLogin yes” >> /etc/ssh/sshd_config &&
echo “Port ${DEBUG_SSH_PORT}” >> /etc/ssh/sshd_config &&
echo “PasswordAuthentication yes” >> /etc/ssh/sshd_config &&
echo “PermitEmptyPasswords yes” >> /etc/ssh/sshd_config &&
su -c “env” $SSHUSERNAME > /etc/environment &&
echo “$SSHUSERNAME:” | chpasswd -e

RUN rm -r /etc/ssh/ssh*key &&
dpkg-reconfigure openssh-server

I am not sure why it is using chpasswd here.

14

That chpasswd is setting an empty password for the SSHUSERNAME user inside the container.

Have you tried removing your device from the Torizon tab and re-adding it? Is it possible that the password on the device is different from what you entered when you added the device into the extension?

15

No, it’s the same device I have used in both cases. However, I did do that and now it works! So, thank you!!

Steve

16

Can you share a video of the debug session where this is happening? I’ve never seen it ask for a password at that time, and the “chpasswd” call you see is just clearing the password and not asking for one.

17

Actually, no, not now. The removal and add made that go away.

However, I am not out of the woods yet. While it linked and I was able to get into the program to debug, it only gets to a point, where some sort of boost exception happens, that doesn’t happen on the old system. I thought maybe it was something to do with writing to the SDCard, but it’s the same code. I’ll do some more debugging and see what I find.

Well, not a video, but I found after I ran the other program and stopped it, when I used the newer version I got the password error:

  • Executing task: DOCKER_HOST=192.168.6.241:2375 LOCAL_REGISTRY=192.168.6.232 TAG=arm64 GPU=-imx8 DEBUG_SSH_PORT=2230 DEBUG_PORT1= DEBUG_PORT2= DEBUG_PORT3= docker compose -p torizon up -d gimbal3container-debug

WARN[0000] The “DOCKER_LOGIN” variable is not set. Defaulting to a blank string.
WARN[0000] Found orphan containers ([torizon-gimbal3bcontainer-debug-1]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
[+] Running 2/2
:check_mark: Container torizon-gimbal3container-debug-1 Started 0.3s
! gimbal3container-debug Published ports are discarded when using host network mode 0.0s

  • Terminal will be reused by tasks, press any key to close it.

  • Executing task: ssh -p 2230 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no torizon@192.168.6.241 rm -rf /home/torizon/app

Warning: Permanently added ‘[192.168.6.241]:2230’ (ED25519) to the list of known hosts.
torizon@192.168.6.241’s password:

The containers are not the image name, but I have had bad interactions before. I’m going to remove all the old images on the device reboot it clean and try again.
Steve

This had no effect.

18

@drew.tx
Is there a way to get the version of the compiler used in the docker.sdk? I tried making it print it out during the build of the sdk, but I can’t seem to get that to show.
The exception happens when I try to actually use the logging system and it is in a gcc c function because it’s in the libc.so that it uses.

I have tabled this for now, since I can’t see to get any further, but if you have any suggestions as to what it is, or where to look, I am sure I would find it useful.

Steve

19

Hi @EvetsMostel1

The simplest way I can envision it is to just modify the Makefile to call ‘gcc -v’ at some point. Then it will show in the output window.

20

Thanks, @drew.tx. I will try that when I get a chance.