Guard base-n target against parent-project collision#184
Merged
bkaradzic-microsoft merged 1 commit intoJun 5, 2026
Merged
Conversation
When JsRuntimeHost is embedded via FetchContent in a parent project that already declares its own 'base-n' INTERFACE target (e.g. BabylonNative), the unconditional add_library(base-n INTERFACE) here fails with "add_library cannot create target 'base-n' because another target with the same name already exists". Guard the whole block with NOT TARGET base-n so the parent-provided target wins, matching the standard CMake subproject pattern (and BabylonNative's own 'if(NOT TARGET glslang)' guards). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the top-level CMake configuration to avoid redefining the base-n target when JsRuntimeHost is included as a subproject in a parent build that already provides a base-n target (e.g., via FetchContent). This prevents CMake configure-time failures due to duplicate target names while keeping standalone builds unchanged.
Changes:
- Guard creation of the
base-nINTERFACE target behindNOT TARGET base-nwhenJSRUNTIMEHOST_POLYFILL_FILEis enabled.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
bghgary
approved these changes
Jun 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When JsRuntimeHost is embedded via FetchContent in a parent project that already declares its own
base-nINTERFACE target — e.g. BabylonNative, which uses base-n for its Window/Canvas polyfills — configuring fails:This surfaced now because the merged File / FileReader polyfill (#169) switched its base64 encoder over to the
base-ndependency, and BabylonNative declaresbase-nbefore it fetches JsRuntimeHost.Fix
Guard the
base-nblock withNOT TARGET base-nso that when a parent project already provides the target, JsRuntimeHost adopts it instead of redeclaring. This is the standard CMake subproject pattern and mirrors BabylonNative's ownif(NOT TARGET glslang)guards. Standalone JsRuntimeHost builds are unaffected (no pre-existing target → block runs as before).Validation
NAPI_JAVASCRIPT_ENGINE=Chakraconfigure +UnitTestsbuild: green, File polyfill + base-n link as before.