Open das-g opened 4 years ago
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?
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.
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.
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.
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:
(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.