feature/relative-plugin-paths

[jolavillette]

feature/relative-plugin-paths

Useful for testing environments. When running this branch, RetroShare will dynamically resolve the executable's directory and first look for plugins in ../lib/retroshare/extensions6/ and ./lib/retroshare/extensions6/ (relative to the binary's location) before falling back to the hardcoded system path.

[csoler]

I assume that this PR is for testing purposes only so it is not intended to be merged, right?

Also why don't you just do
plugins_directories.push_back("../lib/retroshare/extensions6/") ;
in rsinit.cc ??

[jolavillette]

@csoler correct, it targets testers (typically running several versions side by side) — a normal install is unaffected: the relative dirs simply don't exist there and the system path is still searched. About the plain push_back: a relative path would be resolved against the current working directory, not the executable's location — resolving the exe path (and its symlinks) is the whole point.

[csoler]

It seems to me that this PR is quite a lot of code as compared to what it wants to do, especially that it complicates a lot rsinit.cc and this file it is already pretty long:

• removing duplicate paths is not useful because the plugin manager can easily remove duplicate files by replacing the member std::vector with a std::map<RsFileHash,PluginInfo> (or use some temporary std::map that is later converted to std::vector, in order to avoid changing too much code). It's way simpler indeed to remove duplicates based on hash of the plugins rather than based on expanded directory names (which is system-dependent).

• I don't see the need for a special treatment for relative paths. Just append them to currentExecutablePath() and that's all.

[csoler]

There is a function doing exactly this already: canonicalize_file_name() in glibc. See how it's used in rsdir.cc. It can be called using RsDirUtil::removeSymLinks() which also...removes the symbolic links in the path.