https://github.com/dchristiaens/shard-recon has both C++ and Python commands.

I wonder if the first port of call is whether external projects should be entirely self-contained, or should make use of an already built version of MRtrix3. On 3.0.x, we make a softlink to build, which self-detects that it's being executed for an external project, and links against the shared library / finds #included files in either the linked core or the local project code. That doesn't translate trivially to cmake. But there's nevertheless possibly two prospects that don't involve major changes to the core:

Building of an external project entirely encapsulates the MRtrix3 version it depends upon.
- +ve: Provides strong version matching guarantees
- +ve: Existing cmake ecosystem to handle it
- -ve: Redundant compilation for items from the API used by the external project
- -ve: Possible path conflicts. To my knowledge, a user couldn't have within PATH both a shared DLL for an MRtrix3 core installation, and another shared DLL generated for compilation of an external project, and those two DLLs could have the same filename but be of different versions. Could insert the name of the external project into the DLL(s) it generates to disambiguate? Or external project builds never use shared DLLs? Other solutions?
Building of an external project takes as inputs the locations of MRtrix3 API code and installed shared binaries.
- -ve: Slightly clumsy; the old build softlink technique intrinsically captures both code and shared DLLs, whereas with cmake they'd need to be separate paths provided separately.
- -ve: User could attempt to build external project against any version of MRtrix3, potentially incompatible, outside of control of the external project maintainer.
- -ve: Guessing it's not conventional in a cmake environment.
- +ve: More familiar to MRtrix3 precedent.
- +ve: Reduced redundancy of compilation.

I've a feeling that we'd discussed and were drawn to 1., but don't recall if it was definitive.

Our code might be unusual in that an external C++ command might make use of both a precompiled core DLL and templated source code from the core. Altering for explicit instantiation of plausible templates and possibly a different resolution of shared library generation might modify this, but those might be much larger proposed changes. Plus there's situations where an external project may have some unforeseen template utilisation, which explicit instantiation into a shared DLL wouldn't cover.

(Can edit in light of suggested modifications or complete alternatives)

Does anyone know of any other neuroimaging analysis packages that support any form of "extensions" where we might see precedent / success or horror stories?

External projects for 3.1 #2901

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions