TheChymera
commented
4 years ago @neurolabusc here's a video of what's going on: http://chymera.eu/debug/mricrogl/resources.mp4
Closed TheChymera closed 4 years ago
TheChymera
commented
4 years ago @neurolabusc here's a video of what's going on: http://chymera.eu/debug/mricrogl/resources.mp4
neurolabusc
commented
4 years ago 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).
neurolabusc
commented
4 years ago 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.
TheChymera
commented
4 years ago @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 filesNothing against checking it, but I think /usr/share is a much more important location to add.
neurolabusc
commented
4 years ago Added /usr/share to search path. Where does your Linux distribution install FSL?
TheChymera
commented
4 years ago This is our file list for fsl: fsl_flielist.txt
neurolabusc
commented
4 years ago Wow, so your $FSLDIR is /usr/bin, not /usr/local/fsl. Tell me if the latest modifications resolve your issues.
TheChymera
commented
4 years ago @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?