Make FluidFilesPath class more robust #200
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Non-urgent quality of life improvement for devs:
It's a relatively trivial change, but smacks of Being Clever, so I'd be grateful if @tedmoore could look it over and see if there's something I've not considered.
FluidFilesPathworks ok at the moment, but relies on a relative path formulation to guess where the resources directory is.I've come across an edge case that breaks this whilst putting together an improved development experience that creates a mimic of the final installed package layout, but with symlinks for everything*. At this point, using a relative path in sclang breaks, because it just sees through the symlinks and looks in the wrong place for the resources folder.
What this does instead is – once – scans through all the packages that
Main.packagesknows about, and looks for path matches likely to be unique to flucoma (Resources/AudioFiles/Tremblay*), in order to reliably locate the actual package directory on disk (whether populated by symlinks or not).* Which is really cool (you can edit classes and help files in place, and everything just works! Except this) – it's all part of a cmake overhaul