Summary
Refactor the MNX build integration to stop relying on the optional system-installed mnxdom path and instead use a repository-managed dependency flow (planned submodule-based approach).
Background
In #33958, the fetched mnxdom revision was updated to a newer upstream commit to support the schema/API surface now required by the MNX import/export code. The current MSS_USE_SYSTEM_MNXDOM path in src/importexport/mnx/CMakeLists.txt does not enforce compatibility with that same API level, but this cannot be cleanly resolved within the current build approach.
Per the PR discussion, the intended follow-up is to refactor the build so that mnxdom is handled via a submodule and the need for a system-installed fallback is removed.
Affected area
src/importexport/mnx/CMakeLists.txt- MNX build/dependency wiring for
iex_mnx
Requested changes
- Refactor
mnxdom integration to use the planned submodule-based build approach.
- Remove or otherwise retire the
MSS_USE_SYSTEM_MNXDOM path if it is no longer needed.
- Ensure the build uses a single controlled
mnxdom source that matches the API/schema requirements of the MNX import/export code.
Rationale
This avoids configuration-time ambiguity where a system package may not match the API level expected by the source tree, and it aligns dependency resolution with the intended long-term build structure.
Acceptance criteria
iex_mnx no longer depends on an unconstrained system mnxdom package path.- The build configuration documents and uses the repository-managed
mnxdom dependency flow.
- MNX import/export code builds against the intended
mnxdom revision/API surface without needing separate system-package compatibility handling.
Backlinks
Requested by: @rpatters1
Note: assignment to @rpatters1 was requested in the PR discussion, but may need to be applied manually if the integration lacks assignee permissions.
Summary
Refactor the MNX build integration to stop relying on the optional system-installed
mnxdompath and instead use a repository-managed dependency flow (planned submodule-based approach).Background
In #33958, the fetched
mnxdomrevision was updated to a newer upstream commit to support the schema/API surface now required by the MNX import/export code. The currentMSS_USE_SYSTEM_MNXDOMpath insrc/importexport/mnx/CMakeLists.txtdoes not enforce compatibility with that same API level, but this cannot be cleanly resolved within the current build approach.Per the PR discussion, the intended follow-up is to refactor the build so that
mnxdomis handled via a submodule and the need for a system-installed fallback is removed.Affected area
src/importexport/mnx/CMakeLists.txtiex_mnxRequested changes
mnxdomintegration to use the planned submodule-based build approach.MSS_USE_SYSTEM_MNXDOMpath if it is no longer needed.mnxdomsource that matches the API/schema requirements of the MNX import/export code.Rationale
This avoids configuration-time ambiguity where a system package may not match the API level expected by the source tree, and it aligns dependency resolution with the intended long-term build structure.
Acceptance criteria
iex_mnxno longer depends on an unconstrained systemmnxdompackage path.mnxdomdependency flow.mnxdomrevision/API surface without needing separate system-package compatibility handling.Backlinks
Requested by: @rpatters1
Note: assignment to @rpatters1 was requested in the PR discussion, but may need to be applied manually if the integration lacks assignee permissions.