Closed TheChymera closed 4 years ago
@neurolabusc here's a video of what's going on: http://chymera.eu/debug/mricrogl/resources.mp4
The README.md notes that /usr/local/share/MRIcroGL/Resources
is one of the searched locations. I will add /usr/share/MRIcroGL
, but can you test out the methods noted in the documentation (e.g. either /usr/local/share/MRIcroGL/Resources
or setting the environment variable MRICROGL_DIR=/usr/share/MRIcroGL
).
I have updated the README.md section Deploying MRIcroGL
to describe the more exhaustive search for the Resource directory. The changes to source code are made to the shared Metal-Demos files, so make sure you update your Metal demos when you recompile.
@neurolabusc are you sure you added /usr/share/MRIcroGL
to the directories? both in the respective commit, and having built MRIcroGL with the latest Metal-Demos, I only see it looking under /usr/local/share/MRIcroGL
.
/usr/local
is pretty nonstandard and not really used by any other packages:
chymera@silenthost ~ $ tree /usr/local/
/usr/local/
├── bin
├── lib
├── lib64
└── sbin
4 directories, 0 files
Nothing against checking it, but I think /usr/share
is a much more important location to add.
Added /usr/share
to search path. Where does your Linux distribution install FSL?
This is our file list for fsl: fsl_flielist.txt
Wow, so your $FSLDIR is /usr/bin
, not /usr/local/fsl
. Tell me if the latest modifications resolve your issues.
@neurolabusc yes, we install FSL so that it more-or-less respects the FHS. Ofc it would have been better if upstream fixed the issue themselves, but being such a large project the fix is not as easy as here and the project moves more slowly. The core issue which the FSL developers were trying to mitigate by having their own directories, is that they have very many executables whose names would potentially conflict with other packages (it doesn't even really solve that issue very well, since even if they do not conflict on disk, the names may still conflict in the $PATH
). The best solution for that would be sub-commands as for git, but again, this requires significant upstream commitment. For the time being, however, our set-up allowed us to check if there are indeed any conflicts to motivate this, and surprisingly, for FSL, the answer thus far is no. We had an issue with AFNI once but the developers were kind enough to fix this, and wise enough to just rename the binary and not try to create their own directory. Sub-commands would have been better still, but this is sadly and very understandably not immediately feasible.
More to the point, though, MRIcroGL works now, thank you so much!
Having compiled and installed the following files:
I get lots of issues from MRIcroGL, and while the interface starts, it's not able to do much (I can try to do a video recording if the exact behaviour is of interest to you).
I am assuming perhaps MRIcriGL does not find the files under
/usr/share/MRIcroGL
(which would be the correct place to install them according to the FHS). Is this the case? And if so, how can I tell it to look in the right place?