Holoscan SDK Source Builder
Build Holoscan SDK from source in a Docker container and produce a local CMake-consumable installation tree.
The skill states Linux, NVIDIA GPU, Docker, GPU passthrough, and disk requirements, and provides some recovery guidance; however, it includes sudo, remote curl commands, system repository changes, and privileged Docker GPU access without explicit pre-execution confirmation, dependency verification or pinning, data-flow disclosure, and complete rollback guidance, so points are deducted.
The workflow is coherent and covers prerequisites, build, tests, cache clearing, and common failures; the benchmark report also claims high correctness. However, this is a static review with no execution, commands and ./run options depend on an external repository version, and abnormal-input and failure-diagnosis coverage is limited, so the static ceiling and uncertainty reduce the score.
The purpose, audience, trigger condition, and non-fit cases are fairly clear, including debug, aarch64, and iGPU scenarios, and the evaluation includes a negative pip case. However, it is limited to Linux with NVIDIA GPU support, provides no Chinese-language guidance, and relies on overseas documentation, repositories, and dependencies without mainland-China reachability alternatives, so points are deducted.
The material includes frontmatter, version, license, author, tags, progressive steps, limitations, tests, and troubleshooting. It lacks the recommended Instructions and Examples sections, a changelog, a dependency/version matrix, and a clearly defined maintenance update path; the skill-card output description is also broad, so points are deducted.
The core goal is to guide a source build and produce a CMake-consumable install tree, with directly usable commands, build types, tests, and output paths. The benchmark reports positive tasks and high effectiveness, but static review cannot verify actual artifacts or test success, and users still need version- and environment-specific adaptation, so the score is limited by the static ceiling.
The skill references official documentation and the upstream repository, while the evaluation files provide tasks, expected behavior, and summary results, giving some auditability. However, there are no skill-specific committed tests, CI logs, or independently reproducible execution records; the benchmark is primarily a claimed report, so points are deducted.
- Before execution, obtain confirmation for sudo, system repository changes, remote downloads, and privileged Docker GPU access; review remote scripts, images, and dependency sources.
- Pin a Holoscan-compatible commit or tag and verify CUDA and architecture parameters; the documented ./run interface may change upstream.
- The build and tests may consume about 20 GB of disk, GPU resources, and substantial time; a complete cleanup or rollback procedure is not provided.
- For mainland-China users, verify reachability of NVIDIA documentation, GitHub, container registries, and package repositories, and prepare mirror or offline alternatives.
What does this skill do, and when should you use it?
This skill guides users through building, installing, and testing Holoscan SDK from its source tree with the in-tree ./run script. The build runs inside a Docker container with NVIDIA GPU support, so it is not a true bare-metal build. It is intended for cases where published Conda, container, apt, or wheel packages do not provide required debug symbols, custom CMake options, or supported configurations. The resulting install tree can be consumed by local applications as a CMake dependency.
Checks git, Docker, NVIDIA GPU passthrough, and Docker buildx; clones nvidia-holoscan/holoscan-sdk and can switch to a release tag; runs ./run build with debug, RelWithDebInfo, aarch64, igpu, and dryrun options; runs ./run clear_cache after cache-related option changes; executes named Holoscan example tests; locates build and install directories with ./run get_build_dir and ./run get_install_dir; and explains how to point applications to the install tree through Holoscan_ROOT or CMAKE_PREFIX_PATH.
- A Holoscan developer needs debug symbols or custom CMake configuration unavailable in published packages.
- A Jetson or IGX engineer needs an iGPU build using the --gpu igpu option.
- A developer needs to cross-compile Holoscan SDK for ARM64 and can provide qemu-user-static.
- A user wants to build a stable Holoscan release tag and validate it with the recommended C++ and Python example tests.
What are this skill's strengths and limitations?
- Covers environment checks, source retrieval, building, testing, and CMake integration in one workflow.
- Supports debug builds, release builds with debug information, aarch64 cross-compilation, and iGPU builds.
- Includes concrete troubleshooting for GPU passthrough, buildx, CMake caches, and quoted test regular expressions.
- Requires Docker and is not a true bare-metal build.
- Requires Linux, an NVIDIA GPU and driver, working Docker GPU passthrough, and about 20 GB of free disk space.
- A clean first build is expected to take 10–30 minutes; the source provides no performance data or success-rate evidence across hardware.
- The workflow depends on version-sensitive official installation documentation, but the skill does not fix a specific release, CUDA major version, or complete platform matrix.
How do you install this skill?
Install the environment required by the default skills CLI, then run:
npx skills add nvidia/skills --skill holoscan-install-source --yes
The README does not document the CLI's own installation command. After installation, the skill becomes available when the agent next loads skills and encounters a relevant task.
How do you use this skill?
Ask the agent: “When published Holoscan packages do not meet my needs, guide me through building Holoscan SDK from source and running the recommended tests.” A typical build sequence is:
mkdir -p ~/holoscan/
git clone https://github.com/nvidia-holoscan/holoscan-sdk.git
cd ~/holoscan/holoscan-sdk
./run build
./run test
Before building, consult the official “Build from Source” installation section and the README/DEVELOP.md for the selected release. Those instructions take precedence over the defaults in this skill.
How does this skill compare with similar options?
The skill explicitly recommends using it only when published Conda, container, apt, or wheel packages do not fit. Those package-based methods are therefore alternatives for the same installation decision, but this skill does not document their procedures.