-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New folder structure for C++ code #3012
base: dev
Are you sure you want to change the base?
Conversation
fe28ee2
to
8672261
Compare
@Lestropie tests for |
92b0656
to
ebdaeca
Compare
ebdaeca
to
36f1ccc
Compare
@MRtrix3/mrtrix3-devs This is now ready for feedback (I'd especially appreciate any input on the new version matching logic). |
So it looks like as far as filesystem structure is concerned, you've essentially done the following moves:
? Whereas my thinking had been that it would be:
The disadvantage here is that it would no longer be trivial to take a single directory and say "compile everything in this directory into a single shared object". I don't recall the outcome of the most recent discussion here, whether we wanted to remove such a large shared object in favour of many smaller ones or whether to store within a
Are you able to give a concise description of how it differs? I can see some renaming and some moving of code, but change to the logic isn't jumping out at me. |
So the idea of using
I'm not sure if I understand what you mean here. Isn't that what is being done with this proposal? All code in
Yes, I think we discussed this a couple of weeks ago with @jdtournier. If I recall correctly, our conclusion was unless relinking the commands was long this should ok. However, I do agree that to get the fastest possible build workflow, splitting the code in `cpp/lib ' into separate libraries would be ideal. To do that I think the best thing to do would be to manually specify the libraries needed by individual commands. If needed, we could provide that ability in a future PR?
The logic is roughly the same, but I just wanted a sanity check to be sure that things work as expected. The main change I've done is that now the version mismatch checking is done in |
I had expected that this would just be done based on
I think maybe you're expecting a greater degree of understanding of the proposal on my part than what I currently have, and maybe my comment wasn't precise enough. Previously, we had If instead it is the case that all non-command-specific code is to go into a shared library file, as indicated by:
, then I see no purpose in persisting with a Personally, I would over and above that remove the |
In the meeting this morning with @jdtournier and @bjeurissen, it was discussed that since the separation between |
Thanks @daljit46 - just one minor correction: this is the structure that I think is most logical (though not necessarily the most convenient):
Both folders in We also had a debate about what to name the folder for the main library, as there was a suggestion to name it |
c51c9c4
to
9d8be18
Compare
Just rebased to implement this structure. |
I find that clunky, having two sequential filesystem hierarchy levels that only discriminate between two sub-directories. I personally wouldn't choose that over the intermediate:
This requirement:
takes very minimal CMake code; I don't see why that distinction has to be made at the filesystem level. |
Like I said, most logical, though not necessarily most convenient... The structure you're suggesting is actually what I had in mind initially, and what I'd prefer in practical terms. The |
I think the distinction between
|
- All C++ code has been moved to a new `cpp` folder. - C++ commands now reside in `cpp/cmd`. - We now build a single (shared by default) library that packages all non-gui code previously in `core` and `src` (now in `cpp/lib`). - All gui code in `cpp/lib/gui` is still built separately as before. - Version matching logic for library and executables has been updated.
By setting, CMAKE_FIND_FRAMEWORK=LAST we instruct CMake to not look for header files inside /Library/Frameworks as a first search path. This can cause issue when frameworks like Mono are present on the system, resulting in CMake unable to find the homebrew library headers.
The strategy now matches what we do to get the library version.
This ensures that the version string of library and commands live in separate binary objects. The version matching logic has been moved from app.cpp to command.h to accomodate for this.
- `cpp/lib` is now split between `core` and `gui`, the former contains all code previously under `core` and `src` while the latter contains only GUI code for `mrview` and `shview` - `mrtrix-headless` has been renamed to `mrtrix-core`
9d8be18
to
0913ceb
Compare
0913ceb
to
cabbc74
Compare
This PR aims to partially address #2824 and provide a new folder structure for building C++ code. In particular:
cpp
with all source files for executables reside incpp/cmd
core
andsrc
is now built as a single library insidecpp/lib
(except for contents incpp/lib/gui
).This is still WIP so many things don't work yet, but I'm just posting the changes now to get early feedback on CI.