Location of installed files about mricrogl HOT 8 CLOSED

@neurolabusc here's a video of what's going on: http://chymera.eu/debug/mricrogl/resources.mp4

from mricrogl.

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).

from 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.

from mricrogl.

@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.

from mricrogl.

Added /usr/share to search path. Where does your Linux distribution install FSL?

from mricrogl.

This is our file list for fsl:
fsl_flielist.txt

from mricrogl.

Wow, so your $FSLDIR is /usr/bin, not /usr/local/fsl. Tell me if the latest modifications resolve your issues.

from mricrogl.

@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!

from mricrogl.