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

Rust bindings for MapLibre native #1057

Open
Tracked by #978
nyurik opened this issue Apr 24, 2023 · 12 comments
Open
Tracked by #978

Rust bindings for MapLibre native #1057

nyurik opened this issue Apr 24, 2023 · 12 comments

Comments

@nyurik
Copy link
Member

nyurik commented Apr 24, 2023

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 maplibre/martin#978

@nyurik nyurik added the enhancement New feature or request label Apr 24, 2023
@louwers
Copy link
Collaborator

louwers commented Apr 24, 2023

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

@ntadej
Copy link
Collaborator

ntadej commented Apr 24, 2023

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

@nyurik
Copy link
Member Author

nyurik commented Apr 24, 2023

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

ntadej commented Apr 24, 2023

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

@nyurik
Copy link
Member Author

nyurik commented Apr 24, 2023

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

@ntadej
Copy link
Collaborator

ntadej commented Apr 24, 2023

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: #789

@nyurik
Copy link
Member Author

nyurik commented Apr 24, 2023

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

birkskyum commented May 4, 2023

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

ntadej commented May 4, 2023

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

acalcutt commented May 4, 2023

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

ntadej commented May 4, 2023

We should move the platforms organisation to #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
Copy link
Member

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.

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

5 participants