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

Agree on a crate for linking to libnng #29

Closed
neachdainn opened this issue Jan 27, 2019 · 17 comments
Closed

Agree on a crate for linking to libnng #29

neachdainn opened this issue Jan 27, 2019 · 17 comments

Comments

@neachdainn
Copy link

neachdainn commented Jan 27, 2019

Runng and Nng-rs currently use different crates for linking to the NNG library. If my understanding is correct, that means that anyone who has both Nng-rs and Runng in their dependency tree will have linker issues1. I think it would be wise for us to pick a single "sys" crate that we both use. I don't particularly care if we use your code or my code but we should probably utilize the nng-sys crate name to match the community style.

Nng-rs repository


1: I was going to run a quick test of this but I ran into issues compiling Runng. It's probably something wrong with my environment - I didn't investigate because I don't think it impacts the point I'm trying to make.

@jeikabu
Copy link
Owner

jeikabu commented Jan 28, 2019

I was vaguely aware nng-sys was back in use. It was mostly empty and hadn't been touched in 6 months when I started. I thought we were going to have changes to suit our needs, but in practice it's almost never touched.

I'm fine with moving to nng-sys. Couple of thoughts:

  • Use bindgen
    • NNG being "plain C" it could be a poster-child for bindgen and is painless to keep it up to date
    • I've been using it on macOS/win32/win64/ubuntu and now arm64
    • The only problems I've run into is that sometimes different platforms use different types (e.g. os::c_char is i8 vs u8, enum ends up i32 vs u32)
  • I wish it existed outside a workspace/virtual manifest
    • Rust/cargo has issues here that makes using crate "features" clumsy
    • We could talk to gdamore about putting it under nanomsg org
  • Use caution with the version numbers. 1.1.1-rc.X was the only thing that crates.io, docs.rs, and cargo all agreed with....

@neachdainn
Copy link
Author

neachdainn commented Jan 28, 2019

I did look into bindgen when I took the name over, I just wasn't a fan of the amount of clutter that it generates or how things were named (e.g., things like this and this). That being said, I'm definitely willing to use it now that I'm not the only person using the crate, and perhaps it is more configurable that I originally thought. I am a bit wary about the platform thing, since I just had an issue with that.

I think it would be a very good idea to talk to Garrett and put the nng-sys crate under the Nanomsg org. That's a crate that all wrappers will need to use and, if bindgen is used, won't have any opinions or need to be touched very often. It makes sense to put it somewhere official.

I'm not sure I follow the big about version numbers. Am I doing something that isn't 1.1.1-rc.x? If I'm not, I would definitely like to correct that.


EDIT: I just figured out why I couldn't get Runng to build and I remembered another reason why I decided to not use Bindgen: it creates a dependency on libclang. Right now, the only requirements for the crate are Rust, C99, and CMake which makes it a fairly light project. I suppose a compromise might be to manually run Bindgen on every NNG release? That won't work well with the various platforms. I'm not sure what the best solution in here.

@jeikabu
Copy link
Owner

jeikabu commented Jan 28, 2019

Yeah, that's the compromise of bindgen. You'll get everything wrapped for free, but the naming conventions may not be ideal. You can always add a thin adapter layer if you think anyone would want to use the C functions.

Apparently the portable rust type is std::os::raw::c_char. Need to use that instead of i8/u8.

Admittedly the clang dependency is a bummer. Most "regular systems" probably have clang (even docs.rs does). I have run into problems in VM (like travis-ci) and docker scenarios. Suppose you could change the output folder per-platform and check it in with the source.

To me the most important things are:

  1. Keep it sync'd with libnng
  2. Keep it sync'd with Rust (it should work with past/future versions by using the corresponding version of bindgen)

@neachdainn
Copy link
Author

neachdainn commented Jan 28, 2019

I know that there are people using my version of nng-sys on Android, so I wouldn't be very happy just dropping the Clang dependency on them. I also have plans in the future to use nng-rs on odd platforms that might not have Clang available and are slow enough that I wouldn't want to try and build it.

I don't think there's a major rush to get the unification done, so I'll keep thinking this issue over, but I'm starting to like the compromise I mentioned in my previous post. Manually running Bindgen every release should keep things in sync with both Rust and NNG without having adding the dependency on Clang. We might encounter troubles with odd platforms but we could probably manually patch those without too much effort. It would also allow us to do some cool things with features, i.e., have a set of features that would allow you to select the particular NNG version you want to use.

@jeikabu
Copy link
Owner

jeikabu commented Jan 28, 2019

Sure, sounds reasonable.

@gdamore
Copy link
Contributor

gdamore commented Jan 28, 2019

If you guys want a repo on the nanomsg org, let me know. I'm amenable.

@neachdainn
Copy link
Author

I think that would be very good. I'll have time this weekend to play around with Bindgen and see if I can get a repository that works as the backing for both Runng and Nng-rs.

@jeikabu
Copy link
Owner

jeikabu commented Jan 30, 2019

I went ahead and split off a new repo that should do the trick:

  • Stand-alone crate containing just the NNG library bindings
  • Cleaned up the generated code (docs.rs)
  • Setup initial linux/macOS and win64 builds
  • Updated crate meta-data and docs
  • Added your "build-nng" feature
  • Made no_std compatible

Sent you an invite and it should be a much better starting point for you. With a couple of tweaks should be good to transfer to nanomsg org.

@neachdainn
Copy link
Author

I've only had a few minutes to look over it but it looks like a solid start. Looking through the docs you linked, it doesn't seem like there is really anything that will end up being platform specific, so I'll play around with removing the Bindgen dependency (or perhaps put it behind a feature?) this weekend. I'll submit a merge request once I have one ready.

What exactly is the legacy-111-rc4 feature?

@jeikabu
Copy link
Owner

jeikabu commented Feb 1, 2019

legacy-111-rc4 is temporary so I can still get the old bindings. It's safe to remove since this is definitely looking like the way forward. I have a branch with the needed changes to runng.

Removing that junk got rid of 20KB of binary (seriously) so you're right you may be able to make bindgen optional. I'm rooting for you.

Feel free to change readme or anything else, I'm not attached to any of it.

@neachdainn
Copy link
Author

My first set of changes is ready for you to look at over at the pull request.

@jeikabu
Copy link
Owner

jeikabu commented Feb 22, 2019

How are things looking in nng-rs? Have had a chance to look into integrating the common lib? Run into any problems?

@neachdainn
Copy link
Author

I will try to do this tonight and will make it a priority over the weekend if I don't find the time today.

@jake-ruyi
Copy link
Collaborator

No rush, was just curious if it looked like it could work for you.
My plan is to wait for what will probably be nng 1.2 since it includes a number of API changes. Release that as the final version of runng-sys, and then two weeks after that just do a package swap for the shared nng-sys.

@neachdainn
Copy link
Author

That sounds like a good plan. Do you have any idea when the nng 1.2 release is going to be? I didn't look too long, but I couldn't find anything about it in the repo.

@gdamore
Copy link
Contributor

gdamore commented Feb 23, 2019 via email

@jeikabu
Copy link
Owner

jeikabu commented Apr 28, 2019

Everybody is using nng-rust so closing this.

@jeikabu jeikabu closed this as completed Apr 28, 2019
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

4 participants