Build: per plugin version check #208
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
OK, I added a macro to get the API version (relatively tricky, but it should work well), and macros to easily make a plugin depend on a specific one. |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Introduce a macro for a particular plugin to depend on a Geany version.
The goal would be to replace the global Geany version check in GP with a per-plugin one, allowing to build some bleeding-edge plugins against older Geany if it so pleases the user -- or the other way around, allow plugins to depend on bleeding-edge Geany.
Ideally there would be a similar macro to check for a specific Geany API version, to allow seamless enabling/disabling of plugins depending on some development version of Geany (imagine someone building dev-GP with a slightly out-of-date dev-Geany). But this requires finding out Geany API version, which is currently non-trivial.
For now this PR is mostly a suggestion, and is not so useful without the API version check, as it has a release version granularity, which is not sufficient in all cases.
What do you think? Are the benefits of avoiding build failures with unmatched versions, and allowing building some plugins with older versions of Geany enough to warrant the added complexity of maintaining a per-plugin version check?