Document how to build with system libs instead of vendored libs

[das-g]

I'm considering to package OSM Express for NixOS / nixpkgs. As with many Linux distributions, the preferred way is to let applications use common copies of the libraries provided by the distribution, rather each bringing their own copies of those libraries.

It seems like, except for s2geometry, the libraries required by OSM Express are already in nixpkgs:

• libosmium
• LMDB
• Cap’n Proto
• CRoaring

(When packaging OSM Express, I would also — separately — package s2geometry.)

However I'm unsure how to tell the OSM Express build system to use the distribution-provided libraries rather than the ones included in the source tree, and in the instructions to build from source I didn't find anything about that, either. Ideally, this can be done by passing arguments to cmake instead of having to modify any files in the source tree.

[bdon]

Is the convention for Nix packages to use dynamic linking instead of static? I have preferred doing as much static linking as possible because it makes my own builds easier.

We can parameterize the CMake file to do one or both of 1) letting the OS defaults handle header search/link paths and 2) prefer dynamic builds for libraries https://github.com/protomaps/OSMExpress/blob/master/CMakeLists.txt#L12

Ideally this isn't specific to NixOS though and works the same way for Debian, for example.

Also, the way the build works is it does depend on a specific minor version of LMDB and capn' proto in order to ensure the binary format is the same across languages. Is that something that NixOS allows?

[das-g]

Is the convention for Nix packages to use dynamic linking instead of static?

Dynamic, as with AFAIK most Linux distributions.

We can parameterize the CMake file to do one or both of 1) letting the OS defaults handle header search/link paths and 2) prefer dynamic builds for libraries https://github.com/protomaps/OSMExpress/blob/master/CMakeLists.txt#L12

That'd be great!

Ideally this isn't specific to NixOS though and works the same way for Debian, for example.

I'm pretty sure all distributions would appreciate the possibility of such parametrization. Specifically Debian AFAIK also prefers dynamic linking and system libraries instead of upstream-vendored ones. Which distributions are at all interested in providing a package for OSM Express I don't know. But the parametrization option might also help unofficial packagers (e.g. Debian/Ubuntu PPAs) to provide and maintain clean packages.

[das-g]

Also, the way the build works is it does depend on a specific minor version of LMDB and capn' proto in order to ensure the binary format is the same across languages.

Ah, that's good to know.

Is that something that NixOS allows?

Yes, NixOS can provide several variants of a software, e.g. several versions, even when they provide binaries of the same name, and other software can depend on specific variants. It's usually avoided to maintain several variants or versions when it can be avoided, but when there's a good reason (such as here), it can be done.

[bdon]

If you comment out most of the include_directories https://github.com/protomaps/OSMExpress/blob/master/CMakeLists.txt#L23

then CMake should look for headers in your system header paths like /usr/local/include, /usr/include, etc I believe. It may be easier to write a new CMakeLists.txt following Nix-specific conventions - maybe using this as a starting point - https://nixos.wiki/wiki/C and then we can figure out how to combine them later.

[brawer]

Any thoughts about using the FetchContent cmake directive for building OSMExpress? From reading the cmake docs, it sounds like this might resolve this issue — depending on configuration variables, cmake would either take system packages or download the needed dependencies over git. However, OSMExpress would have to be built with cmake 3.11 (which was released in 2018) or newer.

[bdon]

I haven't used FetchContent but it's worth a shot. Last I checked the most problematic part was S2 which depends on OpenSSL. Bumping CMake sounds good as well.