osmcoastline binary references build path

[sebastic]

The lintian QA tool reported that the osmcoastline binary references the build path, and this may cause reproducibility issues. To quote the tag description:

The listed file or maintainer script appears to reference the build path used to build the package as specified in the Build-Path field of the .buildinfo file.

This is likely to cause the package to be unreproducible, but it may also indicate that the package will not work correctly outside of the maintainer's own system.

Grepping for the build path in the strings of the binary results in:

$ strings /tmp/osmcoastline_2.2.2-1_amd64/usr/bin/osmcoastline | grep "/build/osmcoastline-2.2.2"
/build/osmcoastline-2.2.2/src/osmcoastline.cpp
/build/osmcoastline-2.2.2/src/coastline_ring_collection.hpp
/build/osmcoastline-2.2.2/src/coastline_ring.hpp
/build/osmcoastline-2.2.2/src/coastline_ring.cpp
/build/osmcoastline-2.2.2/src/coastline_ring_collection.cpp
/build/osmcoastline-2.2.2/src/coastline_polygons.cpp

I wonder why these paths to the sources are contained in the binary, and how we can prevent them from being included.

[joto]

Okay, I tracked this down: The default build type for osmcoastline is RelWithDebInfo instead of the more usual Release for CMake projects. This was intentional by me, because without the debug info, it is much harder to get useful error reports from users. (And if you know what you are doing you can always use a Release build yourself or strip the binary.) Unfortunately there is an error in my CMake scripts which enables asserts in those builds. So what you are seeing here are the file names that the assert macro stores internally so that it can report where the assert happens.

There are several ways to fix this, mainly depending on the question of whether I want to keep this somewhat special case of making ReleaseWithDebInfo the default. I have to think about this a bit.

Note that the same issue most likely affects other Osmium-based programs, too, because I am using similar CMake scripts everywhere.

[sebastic]

In the context of Debian packages RelWithDebInfo is preferred, so we can provide dbgsym packages with debug symbols automatically. The binaries are stripped as part of the package build as well.

Perhaps using relative paths for the asserts is a good compromise (e.g. only src/osmcoastline.cpp).

[joto]

I can't change the internals of the assert, so I can't put relative paths in there. But asserts shouldn't be in release builds anyway. I have changed the RelWithDebInfo build to disable asserts and this should fix the problem. Will do a release shortly.

[sebastic]

This issue is resolved by explicitly building (2.2.3) with -DCMAKE_BUILD_TYPE=RelWithDebInfo instead of -DCMAKE_BUILD_TYPE=None as debhelper sets by default.