Marble, the virtual globe and world atlas, at its core is a library intended for reuse, libmarblewidget. This library is done with minimal dependencies to ease usage (e.g. just needs a few Qt5 modules).
The new version of Marble, coming with libmarblewidget v0.26 and released as part of KDE Applications 16.12, is now making it more easy to integrate libmarblewidget in your own software project, when using CMake or qmake as buildsystem.
To link your project to libmarblewidget and find its headers, you can have that in 1-2 lines:
For qmake a qt_Marble.pri file is installed. So in the pro file of your project just add:
QT += Marble
For this to work you have to do one out of these:
- install Marble into the same prefix as your Qt5 installation (e.g. /usr)
- pass
-DMARBLE_PRI_INSTALL_USE_QT_SYS_PATHS=ONto cmake when building Marble - use the environment variable
QMAKEPATHto point to the installation prefix of Marble when calling qmake on your project
For CMake some CMake config files are installed. So in the CMakeLists.txt of your project just add:
find_package(Marble REQUIRED) target_link_libraries(my_project Marble)
No more need for some own FindMarble.cmake file.
The CMake variant is already possible since libmarblewidget v0.25 (part of KDE Applications 16.08).
Learn more about how to use Marble in your project, e.g. by simple examples, at marble.kde.org.
Attracted by virtual constructs 
Is this supposed to make things easier on Mac too, where Marble goes out of its way to build as a standalone app bundle and only that way? That kind of app bundles are meant to be relocatable, which is by definition incompatible with sharing embedded resources with other applications.
The fact that the CMake convenience feature is available since 16.08 suggests that this article is addressed (chiefly) to users of more traditional Unix OS versions than the Mac’s OS.
For giggles, here’s the patch that I’m using with 16.08.2 in order to use shared and shareable resources installed in a more traditional manner as required by MacPorts:
https://github.com/RJVB/macstrop/blob/master/kf5/kf5-marble/files/patch-build-for-macports-16082.diff
The principle is simple: unlink the installation mode from the platform tokens, and introduce an option with a default value that does depend on a platform token. Hardly more difficult to maintain, it just requires a bit of goodwill to ask oneself if a new Mac-specific addition is purely related to the installation mode or to the platform. Note that this still builds an app bundle, but one that contains only the “bundleexec”, application icon and Info.plist .
I see I’ll have to find some time to re-do the patch once more and update https://phabricator.kde.org/D1420 .
This was done without really considering the needs on macOS, but mainly due to the fact hat noone in the current active Marble development team is themselves using libmarblewidget for 3rd-party apps on that OS, by what I as part-time contributor can tell. Same with Windows and Android, btw.
All it needs is people who scratch their itch there, as usual. And people who also maintain things, not just do a one-time patch and then expect maintainers to also overtake support for an OS they have no knowledge about 🙂
Marble is used in digiKam, which has official builds for Mac and MS Windows (and at least for Mac the digiKam maintainer applies his own patches to Marble). Marble is also used in Calligra and Kexi; both projects are being re-introduced to Mac. So yes, I think you have to assume that the Marble widget library is or will be used on every platform where Marble can run.
The build system hacks to build Marble as a standalone app bundle were clearly not made by someone who has no knowledge about the Mac’s OS and it’s being maintained by someone (I had to patch a new bit of code). Yes, I’m proposing a one-time patch that will show how to set things up properly for doing a standalone app bundle build and optionally doing a normal build instead. The people who do the actual development and introduce new things which need special treatment if to be included in a standalone app bundle should be able to follow that lead rather than blindly doing `if(APPLE)`, and put dedicated code into an #ifdef/#else/#endif, don’t you think?
It’s not that I’m unwilling to maintain this aspect, but what I’m certainly not hoping for is introducing a patch which undoes the hardwired standalone app bundle hacks and then having to keep doing that. That’s a bit too much like the proverbial mopping with the tap open and makes me want to scratch someone else’s itch (or go scratch any of my other itches).
Something else about libmarblewidget. For 2 iterations now I’ve noticed that the version in the library name changes without any apparent backwards-incompatible changes to the ABI (or indeed to the compatibility version on Mac). With both .so.24->.so.25 (16.04->16.08) and .so.25->.so.26 (16.08->16.12) I could install a symlink and keep using the new library with digiKam without having to rebuild that (huge) bit of software. Wouldn’t it be more appropriate to use a composite versioning scheme, something like
libmarblewidget.so.2.6
libmarblewidget.so.2 -> libmarblewidget.so.2.6
libmarblewidget.so -> libmarblewidget.so.2
which would allow updating Marble without updating or rebuilding 3rd party software using libmarblewidget?
Re: “without any apparent backwards-incompatible changes”… “apparent” might be key term here 🙂 Digikam might only do a few calls into the API of libmarblewidget, of methods and with structs which by accident are stable enough over those versions.
And having to maintain a stable ABI would imped those who make use of the complete API and improve it further all the time, like especially the apps in the Marble repo itself.
From what I can tell while I have been contributing, so far there was always some ABI change on a new major release, smaller and bigger ones. Given the limited resources of the Marble developers and the lack of simple cross-platform ABI check tools (?), simply always bumping the lib version on a release is currently the best that is possible.
Yes, it would be awesome to have some LTS stable version of libmarblewidget which only gets extended. But xmas passed, and Santa could not deliver more developer time for Marble
About the rest, surely also a matter of developer time to do it right. Even the build code for Marble’s own Android app Marble Maps is currently rather just a quick hack IMHO, so no wonders are to be expected for 3rd-party apps wanting to reuse libmarblewidget. Things need to be improved one step after the other, that is why I added the things mentioned in this post. Still. someone needs to maintain all these features, and most successfully this is done by people also making use of the feature. Anything else only means bit-rot and feedback only if too late (post-release), if ever. There are some people doing Marble development on macOS now and then, that’s why their changes get in, as hope is bigger they would also maintain the specific stuff long time.
I cannot really comment about the macOS/bundle-or-not code in Marble, never cared for that myself so far 🙂 All I can comment is that if no-one is doing bundle-centric builds, everyone else can just do guesswork when it comes to bundle-centric builds, which in the end means: bit-rot.
A CI for macOS builds of KDE software (both bundle-centric as well as the ports-way) would help your interest a lot, as it would allow developers not interested in such proprietary OS or bundle-centric builds to still have a quick way to check if their changes did break existing support.
> Yes, it would be awesome to have some LTS stable version of libmarblewidget which only gets extended. But xmas passed, and Santa could not deliver more developer time for Marble.
Still, I cannot help but think that it doesn’t take that much more time to ask oneself for each new feature whether it’s an acceptable investment to implement it in a way that backwards ABI compatibility is guaranteed. There’s a good tutorial on that somewhere on Qt’s support pages, and I think that in the end this leads to more easily maintainable code.
> All I can comment is that if no-one is doing bundle-centric builds, everyone else can just do guesswork when it comes to bundle-centric builds, which in the end means: bit-rot.
It’s the opposite that happens in a way, and that’s the point I’ve been trying to make. Anyone building on Mac will get what you call a bundle-centric build, there simply is no way around that without patching the build system. And apparently someone is maintaining that because I came across a new cmake snippet to patch in 16.12.0 .
What you call the “ports-way” build is nothing other than a regular Unix/Linux build with just additional or different libraries and/or source files where required. That’s why my patch should be easy to maintain for everyone: do the “bundle-centric” things when a dedicated token is defined, and just do the standard things otherwise. For platform-specific sources and libraries, just keep using the platform token (`APPLE`).
Ultimately things like generating a standalone app bundle or not (and possibly similar questions on other platforms) should be handled through the ECM. Individual project should not be obliged to roll their own implementation unless they have very specific needs, and at least not from scratch.