search

maplibre / maplibre-native

MapLibre Native - Interactive vector tile maps for iOS, Android and other platforms.
https://maplibre.org
BSD 2-Clause "Simplified" License
1.08k stars 318 forks source link

Rust bindings for MapLibre native #1057

Open nyurik opened 1 year ago

nyurik commented 1 year ago

There is currently no way to use MapLibre native from a Rust program. I think we should build Rust bindings, similar to node-js and others.

Eventually, this may be replaced by the MapLibre-rs once it is feature complete, but this maybe a good interim solution.

Martin, MapLibre's tile server, will integrate this once available - see https://github.com/maplibre/martin/issues/978

louwers commented 1 year ago

We are looking to move away from a monorepo, so any Rust bindings should probably live in another repo. What do you think?

ntadej commented 1 year ago

Yes, but I suspect we then also need proper platform support for all OSes.

nyurik commented 1 year ago

Lets separate concerns. For now, all platform bindings live here, so the additional platforms should be added here as well. If we ever split them up, then sure, it will be moved at the same time. Let's not do "partial fragmentation" of some projects being separate, while others are together.

If I was maintaining native, I would prefer the monorepo for these types of work, but I do not, so not my call.

ntadej commented 1 year ago

We put new platforms in separate repositories now, especially if they interface C++ directly and do not need anything else.

nyurik commented 1 year ago

@ntadej if some of the platforms are already in new repos (kinda weird for consistency reasons IMO), than sure.

ntadej commented 1 year ago

It depends, we now have a proposal for Xamarin where they do not need to touch the core to provide bindings. It depends on how much platform-specific stuff you want to replace with rust implementation in rust platform.

Also there was more or less a conclusion to separate bindings out of the core repository (motivated by Metal developments as it's now hard to develop on macOS for example). I'm separating out the Qt bindings as a test/example.

In my opinion it may be useful to wait a few weeks before starting a big endeavour to see what we learn from the exercise. Your opinion is also welcome here: https://github.com/maplibre/maplibre-gl-native/pull/789

nyurik commented 1 year ago

@ntadej sure, but again - all this is orthogonal to the ticket -- it doesn't matter where we put the rust bindings - what's important is that we have a proper place to develop it, test it, release it, etc.

birkskyum commented 1 year ago

We put new platforms in separate repositories now, especially if they interface C++ directly and do not need anything else.

@ntadej Just curios, are there any platforms in separate repos at this point? This list in the readme would be great to keep updated, and it looks like it only contains the platforms in the mono repo

Platforms ⭐️ Android ⭐️ iOS GLFW Linux Node.js Qt Windows macOS

ntadej commented 1 year ago

I'm starting with Qt. I have an initial prototype done, but I want to make it build reliably before I open a PR.

The rest will follow when relevant people want them split and have time to do it.

acalcutt commented 1 year ago

I don't know about others, but one thing I like about the mono repo is it keeps knowledgeable users all in one place. As someone with little c++ skill I have always needed the opinions from contributors of other platform....which I feel would be diminished if they were just looking at the platform they care about.

I'm not sure it makes sense to cast one platform out, unless it is substantially different.

On the other side, I have spend time on the node version trying to make the package so it could build on it's own again and lowering the amount of files would be nice for that. I had to exclude iOS and Android to get it within a uploadable size.

ntadej commented 1 year ago

We should move the platforms organisation to https://github.com/maplibre/maplibre-native/pull/789

It is important to stress platform vs SDK/bindings difference (some people do not like SDK in this context, but maybe it helps here): Individual platform support will still stay in the main repository and keep the feature-parity. What is splitting is all wrappers, additional classes etc. that are not directly related to the core rendering.

birkskyum commented 1 year ago

Tools that could help facilitate this: https://cxx.rs/ (Rust specific - Safer than rust-bindgen) https://rust-lang.github.io/rust-bindgen/ (Rust specific) https://www.swig.org/ (Generic, supports many languages)

cxx.rs seems like the most modern approach to this, but whoever picks up this task would have to investigation a bit more to assess which is the best fit.