External projects - #3393
Conversation
Re-implemented concept demonstrated in #2939.
- 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>
|
|
||
| const std::string project_version; | ||
| const std::string project_build_date; | ||
| std::string project_version; |
There was a problem hiding this comment.
warning: variable 'project_version' is non-const and globally accessible, consider making it const [cppcoreguidelines-avoid-non-const-global-variables]
std::string project_version;
^| const std::string project_version; | ||
| const std::string project_build_date; | ||
| std::string project_version; | ||
| std::string project_build_date; |
There was a problem hiding this comment.
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;
^| // 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; |
There was a problem hiding this comment.
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;
^| // 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; |
There was a problem hiding this comment.
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>
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.
docs/tips_and_tricks/external_modules.rst.