Review Request: add support for Okteta 0.9
Friedrich W. H. Kossebau
kossebau at kde.org
Mon Jun 11 14:51:40 UTC 2012
> On June 11, 2012, 8:01 a.m., Andreas Pakulat wrote:
> > Obviously didn't look at the C++ code, but I can't see any major problems with the cmake code.
> >
> > However I'd suggest you drop the version-numbering from your libraries and public API. This does simply not scale and would also be unecessary when the libs installed a cmake-config-file and a pkgconfig file. With that the majority of buildsystems out there would have very easy ways to ensure that a specific version is found and headers and libraries from the same version are being used. Even with the find-files there are now, one could do a quick try-compile check to verify that the headers found match the libraries.
Yes, writing this patch I rolled my eyes a few times (as well I guess) :) And also raised my fist another time against the Qt signal/slot implementation ;)
But then...
The reason for that version-numbering of the libraries and public API is that I want to support the parallel install of different Kasten versions and even the loading of plugins which use different versions of Kasten into the same process (as I experiment a lot with Kasten I have that at least locally, like a few KParts build on older Kasten versions, as I didn't schedule the time to always port them to the latest). And because Kasten is still far from being near a stable API, every release of Okteta comes with a new version of Kasten (the Okteta core/gui libs as slightly more stable, but then I have a few issues there as well).
So to prevent clashes with include files, library file links and library symbols I turned to the solution with the version-numbering of the API and the library name, like I have seen it e.g. with glib (just that they do not break their API every half a year :) )
If there is a better solution, I am all ears to learn about that.
Installing cmake-config-file and a pkgconfig file is still a good idea, will see to add that to the Okteta/Kasten libs.
- Friedrich W. H.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105211/#review14596
-----------------------------------------------------------
On June 11, 2012, 4:50 a.m., Friedrich W. H. Kossebau wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105211/
> -----------------------------------------------------------
>
> (Updated June 11, 2012, 4:50 a.m.)
>
>
> Review request for KDevelop.
>
>
> Description
> -------
>
> Of course the upcoming Okteta 0.9 again has a different API, so the Okteta plugin will not be build with it. Unless this patch is committed :)
>
> Needs at least kdesdk from svn commit 1299667. The SC 4.9 beta2 tarballs, unless rerolled, miss an installed header, so if relying on packages, the only upcoming beta3/rc1 packages are needed.
>
> Backport to 4.3 currently blocked by the messed 4.3 branch, but might be a simple cherry-pick. Okay to also backport and commit, once the 4.3 branch is cleared again? Backport with or without the one string addition?
>
>
> Diffs
> -----
>
> cmake/modules/FindLibKasten.cmake 087eedc
> cmake/modules/FindLibOktetaKasten.cmake 973f0f1
> utils/CMakeLists.txt 1545d8c
> utils/okteta/kastentoolviewwidget.cpp b10974e
> utils/okteta/kdevokteta.rc e5314cf
> utils/okteta/oktetadocument.h 56eba46
> utils/okteta/oktetadocument.cpp abb047d
> utils/okteta/oktetaglobal.h 0113bbb
> utils/okteta/oktetaplugin.h 3eec9f7
> utils/okteta/oktetaplugin.cpp c8a7fd4
> utils/okteta/oktetatoolviewfactory.cpp ed0cf13
> utils/okteta/oktetaview.h 29a6b39
> utils/okteta/oktetaview.cpp 249aaaa
> utils/okteta/oktetawidget.h dfc9907
> utils/okteta/oktetawidget.cpp 0fac371
>
> Diff: http://git.reviewboard.kde.org/r/105211/diff/
>
>
> Testing
> -------
>
> Opened a few files as byte arrays, edited and changed view profiles.
>
>
> Thanks,
>
> Friedrich W. H. Kossebau
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120611/ffea69af/attachment.html>
More information about the KDevelop-devel
mailing list