Question/proposal: Default to -DSKIP_ACE=ON for YARP 3 on Linux/Mac

[jgvictores]

Here's a gutsy question/proposal: Default to -DSKIP_ACE=ON for YARP 3 on Linux/Mac

My personal opinion is that I really like the YARP support for Windows and would not like it to be dropped because of lack of support for ACE, which provides compatibility. However, depending on a library for no known reason, which is the Linux use case, does not seem efficient.

Just opening discussion here. What are your opinions?

[drdanz]

Personally I'm uncertain, but definitely in favour of investigating this.
I've been replacing several the parts using ACE with c++11, in order to limit as much as possible the usage of ACE in YARP. If the number of parts using ACE is very limited, and if everything is properly implemented, I think this is a reasonable option.

I'm a bit afraid that the SKIP_ACE option is not tested enough, though (see for example #1636). Also, until some time ago, there were a few things not implemented, or partially supported, I don't know if current status.

This is a list of the things that we should check/fix, before we can actually make such a switch:

• Fix TcpConnector::connect is blocking with a remote nameserver #1636
• All networking parts should have both implementations, but we should definitely check file by file if that's true, and ensure that the behaviour is the same.
• Multicast wasn't working, but it is working now, thanks to @Nicogene.
• Threads use c++11 threads, but at the moment priority can only be set with ACE or with pthread, there's no macOs native implementation. Also the current implementation is very ugly, casting the native_handle to the ACE thread, I think we should just re-implement this part using the right type returned by native_handle on each platform
• The shmem carrier was built inside YARP only if ACE was enabled, but it is now a plugin, and eventually we can now have YARP_OS without ACE, and still have the shmem plugin built with ACE.
• The old internal logger uses ACE, but I think the SKIP_ACE version should be working. Also we should get rid of that at some point... (related os/impl/Logger: Remove ACE implementation #1646)
• The plugin system has a fully working dual implementation, but the SKIP_ACE version uses dlopen, dlclose, etc. I don't know if this works on macOs
• The yarp::os::Event class has both implementations, I think it is safe to leave just one, since I don't see any specific posix part
• The serialport device uses ACE for connecting to the serial port and there is no replacement at the moment. Anyway it is a plugin, therefore it can link to ACE even if YARP doesn't
• A few devices use ACE, but probably only the deprecated ones, and I think only for marginal things, it should be quite easy to remove.
• A few old examples use ACE (example/game and example/yayarpview), I didn't actually check the code of the examples and I don't know what they do or if they are updated.
• yarpfs (unmaintained) uses ACE for a linked list, we can probably just change that to std::list with minimal effort
• yarpidl_rosmsg uses ACE for fork/execlp but execlp is just a fake implementation (see comment in ,src/libYARP_run/include/yarp/run/impl/PlatformUnistd.h) therefore I'm almost sure that this part doesn't work on windows
• A few other parts in YARP link to ACE because they use headers from OS/impl that include ACE headers
• ACE is required for yarp/os/impl/UnitTests.h used by all unit tests, but I'm already planning to port the unit tests to using the Catch library

[jgvictores]

As said, it's just a proposal, perhaps even a thought experiment. 😃

@drdanz Thanks a lot for looking into this, it's great to at least have a list of features that are expected/missing when using -DSKIP_ACE=ON.

[Nicogene]

@drdanz I can check the points you exposed about macOS 😏

[lornat75]

Both ACE and Posix support are important assets of YARP. Would the following situation be good enough?

• automatic tests on Windows+ACE, Linux+ACE, Linux+Posix,
• field tests on Windows+ACE and Linux+Posix

[francesco-romano]

@drdanz macOS should work if the pthread implementation is Unix specific and not Linux specific
Same for dlopen/dlclose

[drdanz]

About ACE for handling plugins, this part is currently being moved to https://github.com/robotology-playground/sharedlibpp, and it no longer requires ACE