Create VS2015 Connext binaries from source about ros2

[tfoote]

The cmake logic in the source do not support Windows layout. it's all assuming /usr. Will need to modify the cmake to use the Windows style layout.

[j-rivero]

Where I can find the RTI libraries and the documentation to compile them, if any?

[dirk-thomas]

The RTI Connext code is in a private repo on GitHub:
https://github.com/osrf/rticonnextdds-src
That's all we have.

[esteve]

@j-rivero I'll forward you the documentation that RTI sent us with the instructions to compile the repo for Windows, Mac OSX and Linux.

[j-rivero]

I assume that you are currently using a VS2013 compiled binaries distributed somehow. It would be nice to have them to mimic the directory structure and be sure that our content is the same than before. If so, where I can find the installer/zip or any other thing that show me how are you currently using it?

[dirk-thomas]

Please look on the Windows slave where the current version of Connext 5.1 is installed.

[j-rivero]

Having a ROS2.0 installation in my local box, how would you recommend to test local changes let's say against the rmw_connext_cpp (so I don't have to run ament on all the ROS packages and the local changes are preserved)?

[wjwwood]

and the local changes are preserved

I'm not sure I understand what you mean by this.

You can build individual packages with the --only <package_name> option. You can also start with a particular packages and continue from there as normal, skipping the packages that lead up to that with the --start-with <package_name> option. If you use the --symlink-install option it will symlink all installed files, including headers and cmake files, to the install space. That way, if you change a header then you only need to recompile the packages which use the header, avoiding rebuilding the package which installs it. However, I don't think that option works on Windows.

With the ament.py test command you can use --skip-build and --skip-install options to only run the tests and avoid rebuilding and reinstalling them. You can also use the --only and the --start-with/--end-with commands along with the test verb.

[j-rivero]

Thanks William, that was enough to run my tests.

Report from my works:

• I was able to build the 5.2.0 version of RTI Connext with static libs (libraries are using a 'z' postfix), no problem, compiled just fine.
• I have an script to convert from the install layout of 5.2.0 version that we host in the OSRF github, to the same layout that is currently installed in the jenkins node, 5.1.0.
• When I tried our connext_cmake_module with the new version, it failed, it is looking for the shared libraries.
• I tried to compile the 5.2.0 version of RTI Connext with shared libraries, and compilation is broken. There is a good bunch of linking problems when creating the rticonnextmsgcpp component. I spent some hours investigating the problem, but the code base is not trivial to follow and I'm not specially fast on Windows, so I want to ask before going on Update: I just happen to fix the build, not a bad day after all.
• Does someone have compiled this code before or is it the first time we compile it? Using a different VS version? Is the same code we use on Linux/Mac?
• Can I contact someone for asking about the bug? Or should I keep debugging on my own?
• Use static libraries is an option?

[esteve]

@j-rivero it'd be great if your efforts could be integrated upstream, can your script be incorporated into RTI's CMake system? I'm sure Fernando would merge it if we ask him.

[j-rivero]

@j-rivero it'd be great if your efforts could be integrated upstream, can your script be incorporated into RTI's CMake system? I'm sure Fernando would merge it if we ask him.

The script is really no more than a workaround to mimic the previous 5.1.0 installation. We are in contact with Fernando via mail to help with their installation layout design. When it is ready, we should not need the script, just migrating our code (cmake module) to work with the new installation layout.

[dirk-thomas]

Our CMake module in the rmw_connext branch already works with the 5.2 binaries provided by RTI. We should not need to modify them but try to make our custom built binary have a similar layout.

[esteve]

@dirk-thomas agreed. IMHO it's best to collaborate with Fernando to adapt RTI's CMake scripts to produce the same directory layout as the binaries they provide, Fernando's certainly willing to help.

[j-rivero]

Update: I have patched different parts of code involved into getting the 5.2 RTI Connext, and reach until the point of needed a 64 bits compilation of the library. The community version of RTI Connext don't have support for it by default, I'm working on it and contacted upstream about this option.

BTW, I assume that we are not supporting 32bits compilations, right?

[j-rivero]

The good news: I have a 64 bits MSVC 2015 installation (which seems to work fine with our FindConnext.cmake module) of current 5.2 community edition in both, Release and Debug mode and I've sent the patches to upstream.

The bad news: the rmw_connext_cpp is still not able to compile, it is failing in linking with 9 error in symbols coming from constants (DDS_DURATION_INFITINE, ...) which seem present in the code of the libraries being linked. I will look into this tomorrow.

[j-rivero]

Current status:

• 64 bits support is merged upstream
• To build our rmw_connext_cpp we need upstream to merge our patches. Tracker issue.
  • Workaround: custom build from our fork. In your mail.
• rmw_connext_cmake pull request needs to be in to use MSVC 2015, should be ready to merge.

Other non critical stuff:

• Fixing debug/release support: ros2/rmw_connext#86
  • Working with Dirk on it.
• TODO: Create a jenkins job to build the RTI community version.
  • Where should I create the script?
  • RTI repo and our fork are private, so we probably can not release it publicly, can we?
• TODO: I need to port my script that adapts directory layout to patches for cmake upstream
  • As soon as Fernando defines the directory desired layout for the community version (ideally mimic the pro version).

[j-rivero]

The good news: the first build against our Community version 5.2 binary package in Windows is ready.

The bad news: it displays more testing errors than with the Professional version.

[dirk-thomas]

What is the status of building Connext from source? What are the remaining steps and a reasonable time frame for them?

[j-rivero]

What is the status of building Connext from source?

I remember to compiled the source for the first alpha locally after all my PRs were merged. I don't remember to have setup a jenkins job to do it which would be a good idea. If you were asking about the community version, it should be ready to be compiled with VS2015.

Update: I just remember that I've pending to send the proper cmake patches so the community edition is installed exactly in the same directory layout than the professional version so we don't need to modify the paths to fit into our expected layout (from the pro version).

[dirk-thomas]

Can you please continue to make the community a drop-in replacement? Then we can try if it makes any difference regarding the failing tests on Windows.

[dirk-thomas]

This is currently blocked on rticommunity/rticonnextdds-src#14.

[tfoote]

We're working on getting a new VS2017 build now. Closing.