Switching to current Mapbox GL: packaging

[rinigus]

I am switching from Qt Location based QMapboxGL to the current master of Mapbox GL Native. It looks like Qt Location branch has stalled for ~2 years and its time to move on over to the actively developed one. As Mapbox GL Native has changed the build system and can be built reasonably well with cmake, has releases for that cover Qt as well, it makes sense to do this switch.

Now, there are few issues that have to be kept in mind. Something has changed and Mapbox GL has problems when you use larger pitch, such as the default one in Pure Maps (see also mapbox/mapbox-gl-native#15163 for illustration). Issue is currently avoided by reducing pitch from 60 degrees to 50 degrees (72cd029). This commit has been added after release, so it has to be included in the packaging as well.

In addition, while cmake based build system works, it is missing install targets. PR has been submitted, but it takes time with the review (mapbox/mapbox-gl-native#16394).

Finally, there was an issue with QML graphics and Mapbox GL that got resolved in the latest release of Mapbox GL QML (https://github.com/rinigus/mapbox-gl-qml).

To overcome the issues, there is a special branch of Mapbox GL Native in https://github.com/rinigus/mapbox-gl-native/tree/mapbox-update-200607. Depending on the distribution practice, you may want to just include the patch and take the sources from the upstream. Diff is mapbox/mapbox-gl-native@master...rinigus:mapbox-update-200607 .

Suggested cmake configuration parameters for Mapbox GL Native are as in flathub/io.github.rinigus.PureMaps@9d1f993.
The same commit includes required changes in used Pure Maps and Mapbox GL QML versions as well.

I am testing currently the response on Sailfish and it seems to work fine on my device. Same on PC. Will also take care of Flathub update. However, it would have to be also tested on Ubuntu Touch (@jonnius) and Postmarket OS (@PureTryOut).

Let's keep this issue up to share problems with it and to ensure that we are more or less in sync.

• Sailfish OS: currently testing, packaging done
• Ubuntu Touch
• Postmarket OS
• Flatpack: issues with L5 hardware stack. Looks to be fixed now with Mesa update

/cc @jonnius @PureTryOut

[rinigus]

Forgot to mention: due to the bug with pitch, when using 60 degrees for testing navigation, I managed to blow 20K tiles allocation in a day. So, watch out for the quotas and make sure that you use current Pure Maps master where 50 degrees are used.

[jonnius]

Seems to work fine on Ubuntu Touch. Something specific I need to test?

[rinigus]

Try to check whether map tilting leads to issues. For that, calculate a route from your location and try to start navigation. Pause/Start several times, zoom in / out while tilted. This resulted in some errors in Purism L5 GL stack when tested by its users. So, let's see if you are OK.

[jonnius]

Tilted Map seems to be fine. See #391 for the changes.

[rinigus]

Sounds good. I will review tomorrow, will not manage to do it today.

[Olf0]

Since this switch happened, neither Mapbox GL Native bindings for Qt QML (v1.6.0 and higher), Pure Maps (v1.28.0 and higher) or OSM Scout Server (v1.16.1 and higher) are shown as updates in Storeman on my XperiaX@SFOS3.2.1. It seems to be stuck at Mapbox GL Native bindings for Qt QML 1.5.0, Pure Maps 1.27.2 and OSM Scout Server 1.16.0.
I have not yet analysed, which dependencies cannot be resolved under SailfishOS 3.2.1, because I assume you might know it right away: Is this just due to the default settings of a new SailfishOS-SDK version or are you really relying on RPMs from SailfishOS 3.3.0 and higher?

I hope this does not turn out to be more or less a duplicate of rinigus/osmscout-server#318, because SailfishOS 3.2.1 is not really old, yet.

[rinigus]

@Olf0, that is correct, it is the same reasoning as in rinigus/osmscout-server#318 . gcc has been updated to 8.3 in SFOS 3.3.0. As a result, I can use system-provided gcc instead of https://build.merproject.org/package/show/home:rinigus:toolbox/opt-gcc. However, the builds are not usable on older SFOS versions, as you found out.

Newer gcc (opt-gcc or system-provided) are required for building Valhalla (lib used by OSM Scout Server and Mapbox GL Native). When building with opt-gcc, I have to use static linking for libstdc++ as provided by opt-gcc. Otherwise, we get conflicts/incompatibilities with the system provided one.

With new Mapbox GL Native lib, I could not make it compile and work properly using static linking. It maybe down to CMake build files as used in that project. So, opt-gcc was not viable solution. In addition, it makes sense to use system-provided gcc if it works fine, as it does for SFOS now.

If I wish to start supporting older SFOS versions, I would probably have to use older qmapboxgl as we did before. In addition, I would need to write separate SPEC files or make them conditional. In the end, it is maintenance load. As the mapping software stack is large and, apart from platform-specific issues, I am the only one who contributes to it, I decided to focus on the newer versions instead. In addition, I would like to work on few other projects that I think are important for our community which, inevitably, makes allocated time smaller for maps.

These days, as I can test all code on PC, SFOS versions are compiled only at OBS. In principle, it is not very hard to make the needed builds using already available opt-gcc for older SFOS versions. But, as mentioned above, it would have to use older qmapboxgl. It maybe even compatible with the latest versions for now, but I am not sure (for example, not sure whether setGestureInProgress was there before). All would require someone to take time and check if it will work.

[Olf0]

Thank you for the detailed explanation.
I actually missed or forgot about the former use of opt-gcc.

I think it is O.K. the way it is, even though a bit unfortunate.
But trying to support SailfishOS versions before 3.3.0 by recent versions of Pure Maps, Mapbox QML and OSM Scout Server appears to be too resources hungry for the small user-base which might benefit.

[rinigus]

Flatpak version has switched as well. Now pmOS is the last one left.

[PureTryOut]

Sorry, we're (I am) a bit busy with readying postmarketOS for the upcoming PinePhone pmOS community edition. I'll probably take a look at it next week, maybe if I can find some time this week.

[rinigus]

Good luck with PinePhone + pmOS! No problem, we will wait till it is ready over here.

[rinigus]

Closing it here - surely pmOS will catch up at some point. As there is a major change coming up in the build system, it will be an opportunity for pmOS to review dependencies as well

[PureTryOut]

You seem to be switching from pure Makefiles to QMake? May I ask why? QMake is falling out of favor and even Qt itself is going to stop using it with Qt 6.0. Why not use something like Meson or CMake instead?

[rinigus]

Switch from pure Makefile was made as I am going to use C++ code in the future development as well. So, some switch was needed when compared to pure Python/QML combo.

qmake was used as I am familiar with the tool. To my understanding, qmake will stick around in Qt 6 as well. Although, I don't mind switching to cmake if there are volunteers who would like to rewrite build system.

Speaking of build systems and Mapbox GL: I have submitted mapbox/mapbox-gl-native#16394 and would like to ask CMake related question. Is there cross-platform way to make targets for make install? I used GNUInstallDirs and I'm not sure it works everywhere. Alternative would be to skip make install and let packagers shift files around, but it looks to be rather odd.

[PureTryOut]

Afaik GNUInstallDirs works everywhere. It's called "GNU" because it follows the GNU standard installation directories, but it doesn't actually depend on anything GNU, it's literally just a few directories to place things in.

It probably won't work on Windows (no clue though), but it works on anything else.