gui-apps/organicmaps: fix compilation

[vitaly-zdanevich]

In the next PR will add versioned ebuild.

Based on #185

@gerion0 Please review

After emerge I see this in logs - should I do something with that?

 * QA Notice: Files built without respecting LDFLAGS have been detected
 *  Please include the following list of files in your report:
 * /usr/bin/OMaps

[gerion0]

• My PR contained a lot of additional dependencies. Have you checked that they are not needed anymore? Please add them, if they are needed.
• Please unbundle harfbuzz as well like I did in my PR.
• My PR contained a commit description that links to the respective upstream PRs and describes what was done. Please add that, too.
• Is utfcpp in a version >4 not needed anymore? I got problems with Gentoo's utfcpp-3.

[vitaly-zdanevich]

Please unbundle harfbuzz as well like I did in my PR.

done.

[vitaly-zdanevich]

• My PR contained a lot of additional dependencies. Have you checked that they are not needed anymore?

Organic Maps compiles and starts. Should I check some additional cases?

[vitaly-zdanevich]

Is utfcpp in a version >4 not needed anymore? I got problems with Gentoo's utfcpp-3.

Currently in the main tree we have ~utfcpp-4.0.6

[vitaly-zdanevich]

Should I add to Guru remaining EGIT_SUBMODULES

3party/just_gtfs
3party/protobuf/protobuf
3party/fast_obj

?

[vitaly-zdanevich]

My PR contained a commit description that links to the respective upstream PRs and describes what was done. Please add that, too.

Done. Its ok now?

[stkw0]

Fix the PYTHON_COMPAT and also use a versioned ebuild instead of a live ebuild

[stkw0]

At first glance seems protobuf could also be unbundled

[vitaly-zdanevich]

Fix the PYTHON_COMPAT

What fix? Looks good to me

PYTHON_COMPAT=( python3_{7..13} )

[vitaly-zdanevich]

use a versioned ebuild

Ok, but let me please add versioned ebuild after merging of this fix to live ebuild - because anyway we want to have live ebuild as well.

[vitaly-zdanevich]

At first glance seems protobuf could also be unbundled

Tried, got

/var/tmp/portage/gui-apps/organicmaps-9999/work/organicmaps-9999/indexer/drules_struct.pb.h:25:10: fatal error: google/protobuf/generated_message_table_driven.h: No such file or directory

[gerion0]

At first glance seems protobuf could also be unbundled

This does not work unfortunately, see this upstream PR. To document this, I mentioned it in the commit message of my previous PR and asked OP above to do the same.

[gerion0]

Fix the PYTHON_COMPAT and also use a versioned ebuild instead of a live ebuild

The release tarball of OrganicMaps does not contain the needed bundled dependencies. Unbundling is complicated (needs appropriate header patching). However, the bundled dependencies have no releases at all (just_gtfs and fast_obj and an old protobuf. I'm not sure, how to handle this:

1. Download the bundled dependencies as Git repositories pinned to a specific commit?
2. Download the bundled dependencies as tarballs of a specific Git commit (AFAIK, Github supports this)?

[vitaly-zdanevich]

asked OP above to do the same

I added such comments into ebuild itself.

[vitaly-zdanevich]

the bundled dependencies have no releases at all

Created mapsme/just_gtfs#23

[vitaly-zdanevich]

and fast_obj

But I see some releases here

[gerion0]

• My PR contained a lot of additional dependencies. Have you checked that they are not needed anymore?

Organic Maps compiles and starts. Should I check some additional cases?

It compiles and starts on your PC but probably it won't start on a fresh Gentoo install. You can check the binary (for example with ldd) which shared libraries are needed as well and add them as dependencies to fix that.

[gerion0]

and fast_obj

But I see some releases here

Ah, I missed it. Youre right, then you could download the release tarball and copy it to 3party/fast_obj within the ebuild or try to unbundle it by creating the correct patch for OrganicMaps and adding fast_obj as proper package/ebuild here.

[vitaly-zdanevich]

Added dep dev-libs/expat

[vitaly-zdanevich]

You can check the binary (for example with ldd

Thanks, checked - found only two missing deps. Others - deps of existing dep dev-qt/qtbase

[gerion0]

qtbase contains a lot of libraries (managed by use flags). AFAIK, OM links against them directly, so please add them, too (OM will not build, if one of that useflag is deactivated by the user).

[vitaly-zdanevich]

It can be merged, I will add versioned ebuild on the next PR, for smaller atomic PRs.

[stkw0]

commits have to be atomic, not PR. If you are going to add a versioned ebuild, better do it in this same PR

[vitaly-zdanevich]

Have no time now, I am traveling. Better to fix the broken ebuild now, by merging this PR.

[stkw0]

I think it has been broken for so much time we can wait some days. It's also easier to handle one single PR.
btw, I think you should add := for boost and libraries that implement slots so it gets rebuilt if the slot changes.

[vitaly-zdanevich]

Fixed, ready to merge.

[stkw0]

There is multiple errors due to the bundled deps:

 * The following files are causing errors:
 *   3party/imgui/imgui/examples/example_glfw_vulkan/CMakeLists.txt:2.8
 *   3party/osrm/osrm-backend/CMakeLists.txt:2.8.8
 *   3party/osrm/osrm-backend/third_party/libosmium/CMakeLists.txt:2.8
 *   3party/fast_obj/CMakeLists.txt:3.0
 *
 * Compatibility with CMake < 3.10 will be removed in a future release.
 * See also tracker bug #964405; check existing or file a new bug for this package.
 * If not fixed in upstream's code repository, we should make sure they are aware.

[vitaly-zdanevich]

Its a warning, I notified the upstream organicmaps/organicmaps#2217 (comment)

[stkw0]

It's a strong reason to try to unbundle at least imgui (already packaged) and fast_obj (which I think there was a WIP PR about it already) and osrm.

[vitaly-zdanevich]

It's a strong reason to try to unbundle at least imgui

Tried - OrganicMaps is still trying to build its vendored ImGui :(

[vitaly-zdanevich]

and fast_obj (which I think there was a WIP PR about it already

#298

[biodranik]

• Organic Maps embeds all libs so they can work in the same way on all platforms (even where the latest versions of libs are not yet available for whatever reason)
• We often use bleeding-edge master/main branch commits for deps for performance and bugfixes
• We're always keeping libs up-to-date. The latest PR would bump all versions to the freshest ones 3party update organicmaps/organicmaps#12205
• It is very easy to support all versions in one place
• We prefer everyone to use the same tested version of the dependency when we receive bugreports. Otherwise, different/older deps may complicate support.
• If you feel that some Organic Maps dependency is outdated, please let us know or bump it in our repo.
• OSRM can be removed; we don't use it
• You do not need to build everything, building only desktop target is enough. Then most of these dependency issues won't break your builds.

TL;DR; Do not define WITH_SYSTEM_PROVIDED_3PARTY and build only desktop target to distribute OM

[negril]

• Organic Maps embeds all libs so they can work in the same way on all platforms (even where the latest versions of libs are not yet available for whatever reason)

Embedding third party libs is a no go.

• We often use bleeding-edge master/main branch commits for deps for performance and bugfixes

Which is fine for a git build / -9999 but not a tagged release. Adding the required versions for tagged releases is easy and doable.

TL;DR; Do not define WITH_SYSTEM_PROVIDED_3PARTY and build only desktop target to distribute OM

Not defining WITH_SYSTEM_PROVIDED_3PARTY will mean that this won't get accepted.

[vitaly-zdanevich]

Not defining WITH_SYSTEM_PROVIDED_3PARTY will mean that this won't get accepted.

@peeweep can we migrate Organic Maps into gentoo-zh?

[peeweep]

Not defining WITH_SYSTEM_PROVIDED_3PARTY will mean that this won't get accepted.

@peeweep can we migrate Organic Maps into gentoo-zh?

I don't see the point of migrating to gentoo-zh

[vitaly-zdanevich]

Not defining WITH_SYSTEM_PROVIDED_3PARTY will mean that this won't get accepted.

@peeweep can we migrate Organic Maps into gentoo-zh?

I don't see the point of migrating to gentoo-zh

@peeweep
The point is - if here on ::guru they do not like vendoring - when ebuild using a few libs not from the overlay but download them from upstreams.

[vitaly-zdanevich]

Fixed.