Skip to content

External projects - #3393

Draft
Lestropie wants to merge 4 commits into
devfrom
external_projects
Draft

External projects#3393
Lestropie wants to merge 4 commits into
devfrom
external_projects

Conversation

@Lestropie

@Lestropie Lestropie commented Jun 7, 2026

Copy link
Copy Markdown
Member

Alternative to #2939 for addressing #2901.

Where #2939 commenced with modification of the MRtrix3 build tree with the vision that it would help facilitate the building of MRtrix3 as a subproject, here I'm attempting to have the external project template and the requisite MRtrix3 modifications solved at the same time. I have at least adopted the filesystem layout changes proposed in #2939.

More to come when the external project template proposal is posted.

  • Update docs/tips_and_tricks/external_modules.rst.

Lestropie added 3 commits June 6, 2026 21:24
- If an external project builds just one MRtrix3 Python script, then it is necssary for it to additionally build all MRtrix3 C++ binaries.
- Make the Bash executables generated for the Python commands point directly to MRtrix3's app.py for both MRtrix3 proper and for external projects.

Generated-by: Claude Opus 4.8 <noreply@anthropic.com>
@Lestropie Lestropie added this to the 3.1.0 updates milestone Jun 7, 2026
@Lestropie Lestropie self-assigned this Jun 7, 2026
@Lestropie Lestropie added the build label Jun 7, 2026

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clang-tidy made some suggestions

Comment thread cpp/core/app.cpp

const std::string project_version;
const std::string project_build_date;
std::string project_version;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

warning: variable 'project_version' is non-const and globally accessible, consider making it const [cppcoreguidelines-avoid-non-const-global-variables]

std::string project_version;
            ^

Comment thread cpp/core/app.cpp
const std::string project_version;
const std::string project_build_date;
std::string project_version;
std::string project_build_date;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

warning: variable 'project_build_date' is non-const and globally accessible, consider making it const [cppcoreguidelines-avoid-non-const-global-variables]

std::string project_build_date;
            ^

Comment thread cpp/core/app.h
// Populated by an external project's set_project_version() (see command.h, MRTRIX_PROJECT);
// left empty for the core MRtrix3 package so that help/--version/command-history fall back
// to reporting only the MRtrix3 version. Non-const so the external definition can assign them.
extern std::string project_version;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

warning: variable 'project_version' is non-const and globally accessible, consider making it const [cppcoreguidelines-avoid-non-const-global-variables]

extern std::string project_version;
                   ^

Comment thread cpp/core/app.h
// left empty for the core MRtrix3 package so that help/--version/command-history fall back
// to reporting only the MRtrix3 version. Non-const so the external definition can assign them.
extern std::string project_version;
extern std::string project_build_date;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

warning: variable 'project_build_date' is non-const and globally accessible, consider making it const [cppcoreguidelines-avoid-non-const-global-variables]

extern std::string project_build_date;
                   ^

An external MRtrix3 project's Python commands previously reported their
version as "unknown": Parser.__init__ derived it from a run-time
`git describe`, which fails in a cmake-staged build/install tree that
has no .git.

Instead accept the project's build-time-baked version from its generated
launcher, mirroring the C++ mechanism (command.h calls
set_project_version() before usage()):

- _execute() gains an optional `project` module argument and records its
  VERSION/BUILD_DATE into module globals BEFORE the Parser is built.
- Parser.__init__ reads those globals instead of shelling out to git;
  core commands leave them unset and keep reporting version.VERSION.
- MakePythonExecutable.cmake: in external-project mode the launcher now
  imports `<package>.version` and passes it to _execute(); core
  launchers pass project=None, leaving their behaviour unchanged.
- print_version() also reports the project build date, matching the C++
  version string.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant