Feature #1767
Export default plugin folder
| Status: | Feedback | Start date: | 02/13/2014 | ||
|---|---|---|---|---|---|
| Priority: | Low | Due date: | |||
| Assignee: | - | % Done: | 50% | ||
| Category: | Configuration | ||||
| Target version: | rsb-0.18 |
Description
There is some kind of default plugin folder (currently lib/rsbx.x/plugins), where several downstream projects install their plugins (e.g. rst converters, rsb-spread, ...) for convenience. Up to now the downstream projects construct this path by hand.
I suggest that we export e.g. a RSB_DEFAULT_PLUGIN_PATH via cmake config for downstream projects to use. Does that make sense?
Related issues
Associated revisions
Exports the default RSB_SYSTEM_PLUGIN_DIRECTORY via cmake
- May be as install target for rsb plugins by downstream projects
fixes #1767
Exports the default RSB_SYSTEM_PLUGIN_DIRECTORY via cmake
- May be as install target for rsb plugins by downstream projects
fixes #1767
Exports the default RSB_SYSTEM_PLUGIN_DIRECTORY via cmake
- May be used as install target for rsb plugins by downstream projects
fixes #1767
Mention new CMake variable RSB_SYSTEM_PLUGIN_DIRECTORY in news.rst
refs #1767
- news.rst (RSB 0.11): mention new CMake variable
RSB_SYSTEM_PLUGIN_DIRECTORY
Added RSB_RELATIVE_PLUGIN_DIRECTORY in CMakeLists.txt
refs #1767
- CMakeLists.txt: added RSB_RELATIVE_PLUGIN_DIRECTORY
- RSBConfig.cmake.in: use it
History
#1 Updated by Anonymous about 10 years ago
- Description updated (diff)
#2 Updated by J. Moringen about 10 years ago
There seems to be some kind of default plugin folder (currently lib/rsbx.x/plugins)
Yes, RSB configures the RSC plugin loader with a default search path (a list of directories) which contains a prefix-dependent "system plugin directory" (as opposed to user plugin directory in the respective home directory).
Up to now the downstream projects construct this path by hand.
That is indeed suboptimal.
I suggest that we export e.g. a RSB_DEFAULT_PLUGIN_PATH via cmake config for downstream projects to use. Does that make sense?
I think the proposal itself makes perfect sense. I would suggest a different name, though.
Firstly, _DIRECTORY may be better than _PATH because the value of the variable would be a directory, not a list of these.
Secondly, instead of DEFAULT, I suggest SYSTEM to distinguish the directory from the user-specific plugin directory (This would fit into the usual nomenclature of "user", "system", "site", where "site" would be appropriate for organization-wide but not system-wide things).
As a result, I suggest the name RSB_SYSTEM_PLUGIN_DIRECTORY.
#3 Updated by Anonymous about 10 years ago
- Status changed from Feedback to In Progress
- Assignee set to Anonymous
#4 Updated by Anonymous about 10 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset rsb-cpp|commit:18242a2b50f8ca44729ebb39e71629a46f4b92b9.
#5 Updated by Anonymous about 10 years ago
- % Done changed from 100 to 50
I am re-opening this issue, since we have to put a bit more thoughts into this. With the latest changes we export the plugin folder as absolute path (based o the install prefix). However, this can lead into problems, as Christian discovered:
- Downstream projects can't use this path, e.g. when building packages with cpack, as pathes have to be relative for this.
- As an organisational issue: When we build rsb in the toolkit context, the exported plugin directory will point to the toolkit, so that downstream user libraries will try to install their plugins into a toolkit folder.
It seems, that we have to at least export (also?) a relative version of the RSB_SYSTEM_PLUGIN_DIRECTORY and maybe also some kind of RSB_USER_PLUGIN_DIRECTORY (e.g. ~/.rsb/plugins/), which is in the user's home folder and also added to the default plugin path of rsb.
#6 Updated by Anonymous about 10 years ago
- Status changed from Resolved to Feedback
It might be enough to just export the RSB_PLUGIN_DIRECTORY as relative path:
- Downstream projects would install their plugins in the relative path, so into: downstream install prefix +
RSB_PLUGIN_DIRECTORY. This works for installation and cpack package build (it might be necessary to enableCPACK_SET_DESTDIR, cf. source:rsb-cpp|cpack/CPackDebianConfig.cmake#L17, though). - In our toolkit context, downstream libraries included in the toolkit would install plugins in the toolkit plugin folder (as intended). Downstream user libraries will install their plugins into a local plugin folder (downstream install prefix +
RSB_PLUGIN_DIRECTORY), which has to be added to the plugin path configuration.
#7 Updated by J. Wienke over 9 years ago
Arne, any way to solve this for the release?
#8 Updated by J. Moringen over 9 years ago
- Target version changed from rsb-0.11 to rsb-0.12
#9 Updated by J. Wienke about 9 years ago
- Target version changed from rsb-0.12 to rsb-0.13
#10 Updated by J. Moringen about 8 years ago
- Target version changed from rsb-0.13 to rsb-0.14
#11 Updated by J. Moringen almost 8 years ago
- Target version changed from rsb-0.14 to rsb-0.15
#12 Updated by J. Moringen over 7 years ago
- Target version changed from rsb-0.15 to rsb-0.16
#13 Updated by J. Moringen about 7 years ago
- Target version changed from rsb-0.16 to rsb-0.17
#14 Updated by J. Moringen over 6 years ago
- Target version changed from rsb-0.17 to rsb-0.18