Details
-
Suggestion
-
Resolution: Done
-
Not Evaluated
-
None
-
None
-
c2833b1a009bc7c382b30d94109b9b7a25a404a6 (qbs/qbs/master)
Description
Here's an interesting feature idea: module provider plugins.
I wanted to convert the Qt modules to a Probe-based infrastructure (well, I still do), but as previously discussed this would obviously lose the ability to detect arbitrary Qt modules. So I came up with the following idea: add a new plugin class called "module provider". Every time a module is looked up in the search path, the search paths of all loaded module provider plugins are also searched. The plugin can, for example, write its module files to a temporary directory and then return that path. This is essentially the same thing as qbs internally invoking qbs-setup-qt internally every time it is run (perhaps with some caching scheme).
This would allow us to eliminate the qbs-setup-qt tool and its annoying requirement to be manually.
Part of removing qbs-setup-qt would still involve rewriting it to be Probe-based, but the automatic module recognition feature could be reintroduced using this module provider plugin concept. Alternatively, we could opt for laziness and do the module provider plugin mechanism first, which would be easier. Then rewriting for Probe-based modules wouldn't necessarily be necessary, although it would be nicer and arguably easier to modify.
Attachments
Issue Links
- is duplicated by
-
QBS-1414 Generic way to find dependent libraries
- Closed
- relates to
-
QBS-61 support multiple instances of the same logical module
- Open
- replaces
-
QBS-1105 How to support adding pkg-config dependencies to a product
- Closed
- resulted in
-
QBS-1452 parameterization of locating external dependencies
- Reported
For Gerrit Dashboard: QBS-1107 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
249274,11 | Introduce module providers | master | qbs/qbs | Status: MERGED | +2 | 0 |