Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document how to build with system libs instead of vendored libs #20

Open
das-g opened this issue Jul 5, 2020 · 4 comments
Open

Document how to build with system libs instead of vendored libs #20

das-g opened this issue Jul 5, 2020 · 4 comments

Comments

@das-g
Copy link

das-g commented Jul 5, 2020

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.

@bdon
Copy link
Member

bdon commented Jul 6, 2020

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
Copy link
Author

das-g commented Jul 6, 2020

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
Copy link
Author

das-g commented Jul 6, 2020

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
Copy link
Member

bdon commented Jul 10, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants