Any chance for a Linux or Windows build?

[Wazzaps]

This seems really useful and can be used outside of Android

[zhaoquanguo]

Windows Build failed for missing //third_party/lexan/build_defs:lexan.bzl

[bourdakos1]

The Linux build should work, but we don’t have any mediums implemented (e.g. wifi, bluetooth). We only have it for testing purposes at the moment.

The Windows build is currently broken due to some incompatibility issues with our internal build system and open source. We are working on resolving this and will update our documentation with build instructions when we have it working. Once the build is working, we do have several mediums implemented for Windows, so it should be more useful than the Linux version.

hope this helps :)

[aetonsi]

Hi, What's in the works for Windows? Is it a standalone app? A library? An integration with the OS's "nearby share" functionality?

[bourdakos1]

This repo is a collection of libraries. One of which is "Nearby Connections" which is the library used by "Nearby Share" on Android/ChromeOS.

[aetonsi]

So you mean that, for Windows, a port of the library is in the works?

[bourdakos1]

The library already works on Windows, the Bazel build just doesn't work externally since "//third_party/lexan/build_defs:lexan.bzl" isn't open sourced. You could theoretically compile the sources with a different build system or fix the Bazel build and the library would be fully functional.

We are working on replacing the problematic build rules with alternatives so the Windows library can be built more easily.

[proatgram]

The Linux build should work, but we don’t have any mediums implemented (e.g. wifi, bluetooth). We only have it for testing purposes at the moment.

Regarding the Linux mediums and mediums in general, where do they fit in? I've been looking through this repository trying to figure out where the platform dependent code is implemented, which it seems like internal/platform/implementation but I'm not sure where the platform dependent mediums are used or how they are linked in the final library build.

If you could give some information regarding how the mediums are implemented and point me in the right direction to try to implement Linux mediums that would be amazing! :D

[Xlythe]

Each of the platforms needs to implement platform.h. You can see the Windows implementation here. These are then exposed as build rules which then are added as dependencies for each of the client-facing directories under /connections/{language}.

[50-Course]

I was going to add that we need Linux build, happy to find a support issue currently being worked on.. The newer version of Ubuntu (22.10+) allows straight-out connectivity with Bluetooth but this would be nice to have a Nearby share between nearby-share-enabled device and a Linux machine

[proatgram]

In the client-facing directory for c(pp?), I noticed that all of the files were postfixed with a "_w". I'm assuming, by looking at the BUILD file (and implementations for those files), that these are Windows implementations. Adding Linux implementations for connections, would those go in the same directory, possibly postfixed by "_l"? Would it be better organized as two directories? (That is, when it comes time to implement for Linux?)

/connections/c/windows
/connections/c/linux

[bourdakos1]

Originally the code under “c” was written for Windows. However, it is now completely cross platform, so you shouldn’t need to make any changes for Linux there. Also, the “c” directory is a C interface (not C++) so the library can be used by things like Flutter via FFI. The C++ interface is connections/core.h, which we eventually want to move to a “cpp” directory.

[proatgram]

Ahh I see. I think that clears it up. Thank you!
Once implementation is defined and implemented in /internal/platform/implementation/linux and build rules are possibly updated, there would need to be nothing done with under /connections?

[bourdakos1]

Correct, there shouldn’t be any needed code changes under “connections” aside from maybe adding a Linux specific build rule for generating a dynamic library (similar to the windows DLL rule)

[Ankk98]

This looks like a cause that I would like to contribute to. Can we have some issues defined as "good-first-issue"?

[proatgram]

I'm currently working on porting stuff to Linux here, although I haven't been able to compile due to complications with the build system, so a lot of it will probably still need work. I am aiming to make this as similar as possible to the Windows implementation so that it is easier to be picked up and worked on by developers who are used to working with the Windows implementation.

In order to get things to compile, I'm going to try to get a working bazel build, and then see if I can implement CMake.

[vibhavp]

@proatgram Hey! I've also been working on adding a Linux implementation of the platform APIs here. The code entirely uses D-Bus interfaces for setting up mediums, with the initial targets being Bluez, Avahi and NetworkManager for Bluetooth, service discovery, and Wifi/networking respectively. For device info, I've used systemd APIs and the XDG Base Directory spec, so that the library only relies on Freedesktop.org interfaces.
IIUC, we have mostly worked on different classes, so it should be possible to merge our forks. Let me know if you want to collaborate!

[proatgram]

@vibhavp Hey! That's brilliant, I'd be very much interested in collaborating! As of currently I have only been working on helper classes that I was looking at when I looked through the Windows implementation, so, mostly everything except platform.h and all the bluetooth and communication libraries. I figured implementing those first would get me acclimated with the code base at least a little bit, as I've never worked with Abseil or Bazel, or any of the sorts.

I haven't been able to get a working compile with it though due to issues with Bazel that I can't figure out, so I haven't been able to test the implementations I've written. That and another reason has led me to begin adding CMake support so that I can better easily contribute and work on it. That hasn't been pushed to my fork yet though.

[vibhavp]

Update: After merging with @proatgram's branch (thanks!), the platform code at https://github.com/vibhavp/nearby is mostly complete, save for Bluetooth LE support. The currently supported mediums (with their respective backends) are:

• Bluetooth Classic - Using Bluez's D-Bus interface (Caveat: The code uses the default pairing agent instead of implementing its own, and as a result does not use passkeys/pin-codes for pairing).
• WifiLan - Using NetworkManager and Avahi's D-Bus interfaces.
• WifiDirect - NetworkManager
• WifiHotspot - NetworkManager

However, I'm not sure how I would actually test this implementation, is there's a nearby API test app that I can build against the linux platform code to do so? For starters, how do I build //connections:core to use the linux platform?

[bourdakos1]

We have a test app for iOS/macOS: https://github.com/google/nearby/tree/main/connections/swift/NearbyConnections/Example

and an Android sample here: https://github.com/android/connectivity-samples/tree/main/NearbyConnectionsWalkieTalkie

However, we don’t have any open source sample apps for Windows or Linux :(

We have a Dart FFI layer for Connections, so we could try to add a Flutter sample app for Windows/Linux, but I’m not sure how quickly we could make that happen

[bourdakos1]

Also, awesome work!!!!

[proatgram]

@vibhavp That's brilliant!! Glad I was of help! I have connections core somewhat compiling using CMake, although with none of the platform dependent code yet. I'm currently working on static vs shared compilation for each. This should make it a lot easier to develop a test binary on Linux using CMake targets etc.

A problem I realized with the way dependencies are being compiled in with this project and the way Linux handled packages is that if Binary A depends on Library B, and Binary A is to be installed to the system, Library B must also be installed to the system if it has header files that Binary A depends on, or even shared objects (.so or .dll on Win).

This works in Windows (I believe), but in Linux if Library B is installed system wide, for any reason, whether it be a system app needs it, you need it, whatever, installing Binary A will result in Binary A's dependency Library B being installed with it, despite it already being installed system wide, therefor creating a lot of package conflicts and headaches.

This problem needs to be solved before we can start developing actual Linux apps that work with Nearby and it's libraries. CMake can help fix this problem by checking if a package is installed system wide (via find_package) and use that instead of building and installing a conflicting dependency, breaking a lot of system apps. This will prevent Binary A from trying to install Library B, with all of B's headers, overwriting the system installed headers and such of B.

This approach is most likely only desired on a platform such as Linux, since on a platform like Windows I believe apps install everything to a directory under C:\Program Files\ where as Linux doesn't, so app dependencies can't be separated from one another.

I can't wait to see a working app for all platforms, having many devices, of different platform and origin communicating with each other is amazing. The hard work put into this project is amazing!

[proatgram]

@vibhavp I've begun to start adding targets and build rules for the Linux Mediums Implementation, but there are headers referenced in source files and Bazel BUILD files that do not exist, making the compilation fail.
Such files that I have found being:

• internal/platform/implementation/linux/login_manager_client_glue.h
• internal/platform/implementation/linux/login_session_client_glue.h
• internal/platform/implementation/linux/bluetooth_classic_server_socket.h

There might be more but these are the ones that I have found in trying to compile. Could you update the BUILD to what you have currently?

[anayw2001]

Hey! If you guys are willing, feel free to open up a PR with your contributions! I'd love to have a look and maybe give it a spin :D

[vibhavp]

@vibhavp I've begun to start adding targets and build rules for the Linux Mediums Implementation, but there are headers referenced in source files and Bazel BUILD files that do not exist, making the compilation fail. Such files that I have found being:

• internal/platform/implementation/linux/login_manager_client_glue.h
• internal/platform/implementation/linux/login_session_client_glue.h
• internal/platform/implementation/linux/bluetooth_classic_server_socket.h

There might be more but these are the ones that I have found in trying to compile. Could you update the BUILD to what you have currently?

Oops. I've checked in these files, you should be able to build "//internal/platform/implementation/linux:linux" now.

[vibhavp]

Hey! If you guys are willing, feel free to open up a PR with your contributions! I'd love to have a look and maybe give it a spin :D

Sure! Here you go: #2098

[proatgram]

Hey! If you guys are willing, feel free to open up a PR with your contributions! I'd love to have a look and maybe give it a spin :D

Sure! Here you go: #2098

Brilliant! This has come a long way since I first started looking into it a while ago, I'm glad this is finally becoming possible!!

[proatgram]

For the testing source files, where is the symbol EXPECT_OK and ASSERT_OK being defined and included? I can't seem to find them when implementing testing targets.

[proatgram]

@vibhavp I've made progress in implementing a CMake build system if you'd like to take a look at nearby/cmake. Regarding your PR, what needs to be done and what is being currently worked on? I'd like to contribute though time is sparse for me.

[kidfromjupiter]

Any progress on a linux build?

[rajendrasp]

Do you have a Windows build for this library? It would be really helpful.