Skip to Content

Porting 5GAlert to Jetson

4 July 2025 by
CTech Metrology, Luc Wens

Intro from Gemini

Porting a CMake project from Windows using vcpkg to a Jetson Orin will require some adjustments, and Visual Studio Code's handling of packages imported with vcpkg will depend on how you set up your development environment for cross-compilation.

Here's a breakdown of the considerations and how Visual Studio Code fits in:

Challenges and Considerations for Jetson Orin (Linux ARM64) Porting:

  1. Vcpkg and Cross-Compilation:
    • Vcpkg on Windows primarily manages packages for Windows targets. While vcpkg can be used for cross-compilation, it requires specific setup:
      • Triplet Files: You'll need to define a custom vcpkg triplet for your Jetson Orin, specifying the arm64-linux architecture and the appropriate toolchain.
      • Toolchain File: CMake needs a toolchain file that tells it how to find and use your cross-compilation tools (e.g., GCC for ARM64).
      • Package Availability: Not all packages available in vcpkg for Windows will necessarily be available or easily compilable for arm64-linux via vcpkg. Some libraries might have different dependencies or require manual porting/building on the Jetson.
  2. CMakeLists.txt Adjustments:
    • Your current
      CMakeLists.txt 1 shows
      find_package for OpenSSL, Boost, and GeographicLib. While these are common, their availability and how they are linked might differ on Linux.
    • The FetchContent for protobuf and tomlplusplus is a good approach as it pulls sources directly, which simplifies dependency management across platforms, assuming they compile cleanly on ARM64.
    • The MSVC specific options (CMAKE_MSVC_RUNTIME_LIBRARY, /bigobj, TOML_ENABLE_WINDOWS_COMPAT) will need to be handled with if(WIN32) or if(NOT WIN32) blocks, or simply removed for the Linux build, as they are specific to Microsoft Visual C++ compilers.
    • The
      generate_version.bat and generate_version.sh logic is good, as it already handles platform-specific scripting2.
  3. Visual Studio Code and Remote Development:
    • VS Code's "Remote - SSH" Extension: This is the recommended way to develop on a Jetson Orin from your Windows machine using VS Code. You would install this extension in VS Code on your Windows machine.
    • Development Environment on Jetson: When you connect via SSH, VS Code effectively runs a server on the Jetson. Your entire development environment (compilers, CMake, build tools, vcpkg if used on the Jetson) will reside on the Jetson itself.
    • Vcpkg Integration with VS Code (Remote):
      • If you choose to install vcpkg on the Jetson Orin and use it to manage your dependencies natively on the Jetson, then VS Code, when configured with CMake Tools, will be able to find and use those packages. You would typically set the CMAKE_TOOLCHAIN_FILE to point to vcpkg's toolchain file on the Jetson.
      • If you attempt to use vcpkg on Windows for cross-compilation to the Jetson, VS Code on Windows will rely on your local vcpkg installation and your CMake toolchain file to handle the cross-compilation. This is more complex and less common for direct development compared to remote development.

How Visual Studio Code will handle packages:

  • Best Scenario (Remote Development): If you set up your Jetson Orin as a remote development target using the "Remote - SSH" extension and install all necessary build tools and libraries (including potentially vcpkg, or by installing packages via apt or manually building them) directly on the Jetson, then VS Code will function much like it does for native Linux development. It will use the CMake and compiler installations on the Jetson, and if vcpkg is used on the Jetson, it will integrate correctly through the CMake toolchain file.
  • Cross-Compilation Scenario (More Complex): If you try to cross-compile from your Windows machine to the Jetson using vcpkg, VS Code will defer to CMake and your toolchain file. VS Code itself doesn't "handle" the packages; it tells CMake where to find the toolchain and dependencies, and CMake then uses vcpkg (or other methods) to provide them. This setup is generally more prone to configuration issues and might not be as seamless as direct remote development.

Recommended Approach:

  1. Set up your Jetson Orin for development:
    • Install necessary build tools: sudo apt update && sudo apt install build-essential cmake pkg-config git
    • Install any system-level dependencies your project needs (e.g., libssl-dev, libboost-all-dev, libgeographic-dev if you choose not to use vcpkg on the Jetson for these).
    • Decide on your dependency management strategy:
      • Option A (Recommended for simplicity): Rely on apt for system libraries (like OpenSSL, Boost, GeographicLib) and continue using FetchContent for protobuf and tomlplusplus as you are already doing3. This minimizes the complexity of managing a cross-compiled vcpkg.
      • Option B: Install vcpkg directly on the Jetson Orin and use it to manage all your third-party dependencies for native ARM64 compilation.
  2. Use Visual Studio Code's "Remote - SSH" extension:
    • Connect to your Jetson Orin from VS Code on your Windows machine.
    • Open your project folder on the Jetson.
    • VS Code's CMake Tools extension will detect your
      CMakeLists.txt 4 and configure the project using the CMake and compilers on the Jetson.

By using the "Remote - SSH" extension, you treat the Jetson Orin as your development machine, simplifying the dependency management and build process significantly compared to trying to cross-compile from Windows using vcpkg for all dependencies.


Local or remote

Given you have the Jetson on your network, the easiest and most recommended approach is to continue developing on Windows using Visual Studio Code's "Remote - SSH" extension to connect and develop directly on the Jetson.

Here's why and how it benefits you:

  • Seamless Development Experience: The "Remote - SSH" extension makes your Windows VS Code instance feel like it's running directly on the Jetson. You'll have access to the Jetson's file system, terminal, and installed tools (compilers, CMake, GDB for debugging) as if you were working locally on the Jetson1.
  • Leverage Jetson's Native Environment:
    • Toolchain: Your code will be compiled by the GCC/G++ compilers on the Jetson, which are the native compilers for its ARM64 architecture. This eliminates the complexities of cross-compilation toolchains on Windows.
    • Libraries: You can install libraries directly on the Jetson using its package manager (apt) or by compiling them natively. VS Code will then seamlessly pick up these libraries2.
    • Dependency Management: For packages like OpenSSL, Boost, and GeographicLib, you can often install them easily on the Jetson via apt (e.g., sudo apt install libssl-dev libboost-all-dev libgeographic-dev). For
      protobuf and tomlplusplus, FetchContent will work as they are fetched and built from source directly on the Jetson, ensuring compatibility3.
  • Debugging: You can debug your application directly on the Jetson from your Windows VS Code instance using the integrated debugger (e.g., GDB), which is crucial for identifying and fixing issues specific to the ARM64 environment4.
  • Performance: While you're interacting with VS Code on Windows, the heavy lifting (compilation, running, debugging) happens on the Jetson, utilizing its processing power.
  • Minimal Jetson Setup: You only need to install the necessary build tools and libraries on the Jetson, not a full graphical desktop environment or VS Code's UI components, which keeps the Jetson lean.

Why installing VS Code directly on the Jetson is generally less ideal:

  • Resource Usage: Running a full graphical desktop environment and VS Code's Electron-based UI on the Jetson can consume significant resources (CPU, RAM), potentially impacting the performance of your application or other tasks on the Jetson.
  • User Experience: While workable, the graphical experience on the Jetson might not be as fluid or responsive as on your Windows development machine, especially if you're used to a high-performance desktop.
  • Workflow: You'd be switching between two separate environments, potentially copying files back and forth if you still want to leverage your Windows machine for other tasks.

In summary: Set up your Jetson with SSH access, install necessary build tools (build-essential, cmake, git, pkg-config, libssl-dev, libboost-all-dev, libgeographic-dev), install the "Remote - SSH" extension in VS Code on your Windows machine, and develop remotely. This offers the best balance of convenience, performance, and compatibility.

XAI development