Find the astyle library installed in the system, and use it instead of
the embedded copy (which is still used if the system library is not
available).
Details
Details
Builds fine with, and without a system libastyle (the embedded copy is used in the latter case).
test_astyle passes in both cases.
I did not try the plugin for real, though.
Diff Detail
Diff Detail
- Repository
- R32 KDevelop
- Branch
- external-libastyle (branched from master)
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 6288 Build 6306: arc lint + arc unit
Comment Actions
Side note: another approach can be to build the astyle plugin only if a system astyle library is found, i.e. make the plugin optional, and get rid of the astyle embedded copy.
I can adopt that approach -- right now I chose the most "conservative" approach.
Comment Actions
Thanks for the patch, @pino, agreed that system things should be preferred (curious myself why there even is a copy).
No time to look in details currently, but IIRC there are some API changes between astyle versions, so version needs to be taken into account instead of just using whatever is provided by the system. Cmp. commit which upgraded the astyle copy recently: 378a6e02cec55390c6dc903d98a035485ec1aa10
Comment Actions
My idea is to do feature checks at cmake time to adapt to the API changes. I don't have astyle older than 3.1 to test, though (I can help fixing these issues, of course),
Comment Actions
do we have custom patches in our libastyle? I hope not, but it's been too long for me to remember. If not, then I guess we should get rid of our copy of lbiastyle and just disable kdevastyle if that dependency wasn't found - it's pretty optional anyways.
if we do have custom patches, then I wonder if it's safe/fine to use the non-patched version? have you tried, did it work for the common stuff?
Comment Actions
It looks not, at least according to the changes in aecd24c2f384d500de1dc83f8ba3fb4f2fd8323d, and 378a6e02cec55390c6dc903d98a035485ec1aa10.
I hope not, but it's been too long for me to remember. If not, then I guess we should get rid of our copy of lbiastyle and just disable kdevastyle if that dependency wasn't found - it's pretty optional anyways.
I can do that (mentioned in a previous comment).
Comment Actions
Question: does any distro package that?
At least my openSUSE doesn't nor any other distro I know of, only thing I found was:
https://rpmfind.net/linux/rpm2html/search.php?query=libastyle-devel
| plugins/astyle/CMakeLists.txt | ||
|---|---|---|
| 3 | Please check for version 3.*, given the current code relies on its API (and config keys?). Not exactly sure which 3.*, 378a6e02cec55390c6dc903d98a035485ec1aa10 tells which kdevelop-side API changes had be done there. | |
Comment Actions
- add some rudimental version detection of the astyle library, since it provides no pkg-config file nor version macros/variables...
- request libastyle >= 3.1
Comment Actions
- on Debian (and thus Ubuntu and any other derivative) there's libastyle-dev
- on Fedora (and thus any derivative) there's astyle-devel
- on Mageia (and thus any derivative) there's libastyle-devel
- IIRC the Gentoo ebuild builds the library as well
Can you please request openSUSE to package the astyle library? @lbeltrame can you help with this (even if it isn't your realm, you might know who could)?
Comment Actions
Same source, it needs to be enabled passing the right variable to the makefile, or cmake (depending how astyle is built in openSUSE).
Comment Actions
Then the best should be to file a bug on bugzilla.opensuse.org asking for that to be packaged.