Make sockets work on non-Linux Unix systems

[thiagomacieira]

Most of the code was generic anyway, so move it to a "common" file. For the bits and pieces that were specific to Linux, reimplement in a generic version.

This patch series includes #1394.

[thiagomacieira]

@ceolin

[barbieri]

different indentation with line above

[thiagomacieira]

Damn. It didn't show because of 8-space tabs. My OS X's Emacs isn't properly configured for space mode.

[barbieri]

looks good to me, just minor comments. I think we better merge this ASAP and work on details afterwards.

[poussa]

Can we get this moving again. I'd like to see os x support getting in...

@thiagomacieira how to you handle the sol_platform_* APIs. I get link errors when trying this patch.

Don't see any activity in src/lib/common/Makefilewhich I guess needs to be patched and sol-platform-linux-common.cas well.

      LD   build/soletta_sysroot/usr/lib/libsoletta.so
Undefined symbols for architecture x86_64:
  "_sol_platform_impl_add_service_monitor", referenced from:
      _sol_platform_add_service_monitor in sol-platform.o
  "_sol_platform_impl_apply_locale", referenced from:
      _sol_platform_apply_locale in sol-platform.o

[thiagomacieira]

@poussa: I had fixed all such errors. You need to either provide an implementation for those functions (dummy or not) or you need to make sure that their not called in the first place.

The best solution for OS X (and iOS and Android and QNX and Windows, etc.) is to not compile sol-platform.c at all, since one won't be using Soletta to control the platform. It just happens that there's a lot of code leakage inside Soletta that requires functionality from sol-platform.c today, so I provided dummies instead to make the porting easier.

[barbieri]

For Sakari and Nodejs, the route Thiago was doing is okay.

For OSX/Native and iOS where you want to be a guest part of an application, it doesn't make sense to use that route of us providing a mainloop and the likes. For these we should export native (ie: ObjC) modules that use Soletta internally, but it's not exposed. In iOS/OSX this would be a Framework where you compile with XCode and pick only the C files you need from Soletta. The "sol-mainloop-impl-ios.m", for instance, would use the current RunLoop to forward requests. Likewise, the "sol-socket-impl-ios.m" would call recommedend socket APIs (maybe POSIX socket, I'm not sure). These cases should also define SOL_API to empty, so we do not export any symbols from Soletta at all.

And as thiago said, export only what makes sense or what is missing in the platform. Like OIC is missing, MQTT, HTTP are not... I/O (GPIO, I2C...) are not possible, etc.

This is a different case of what Thiago was doing, that is to run soletta applications in MacOS. This one we want Soletta as host main loop, similar to how Qt/Gtk does their porting.

[poussa]

@thiagomacieira I don't see the sol_platform dummy functions anywhere. Where are they? I started to do that but wanted to ask since it seems the only viable solution.

@barbieri My request for this PR has nothing to do with Node.js. I just want to run / debug soletta on OS X since that is my default env. Now I need to start VM (linux) every time I want to use soletta. That is, my request is to run soletta apps on OS X (MacOS).

[thiagomacieira]

@poussa: the specific functions you're listing didn't exist when I wrote my patches. So you're not going to find the dummy functions anywhere.

@barbieri: as far as I am concerned, this patch is done and was ready to be merged 2 months ago. Please take care of it. (don't ask me to resolve the merge conflict, I don't have time; it didn't conflict two months ago)

[barbieri]

I understood you'd merge it.

Okay, I can ask someone in my team to merge and solve conflicts, but will need you to test the build on MacOS.

@cabelitos can you rebase this branch and send a PR so @thiagomacieira can test?

[thiagomacieira]

From @poussa's message, we know it doesn't compile anymore. Someone will need to add the missing functions.