Use of vcpkg.io for dependency management

[j-medland]

Hello

I have had great success with building dependencies for libraries like this using vcpkg from Microsoft - it integrates with CMake (but needs to be version 3.20 or so) but does all the heavy lifting when it comes to building OpenSSL etc on Windows, Linux and Mac.

It really simplified the building for my project asynchronous system exec library if you wanted to get a preview

Cheers

John

[volks73]

Thank you for the recommendation. The vcpkg.io looks pretty good. I don't have a problem bumping to CMake v3.20 or newer for the project. I think this will eliminate the need for the .deps folder and using ExternalProject from the CMakeList.txt file, but the vcpkg package for CMake will be needed.

Can you use vcpkg on NI Linux RT, too?

[j-medland]

I haven't tried vcpkg on NI Linux RT - in theory, it should work but the versions of CMake and git in the NI package repositories might be a bit old.

I have built NI-Linux-RT x64 packages using a Docker image and the NI toolchain. That means I can install the build-tooling for the host system and we don't have to try and get the tools updated on real targets.

I might start there and then try for an arm-package,

[volks73]

Do you have any links or information about building NI Linux RT packages using Docker and NI toolchain? I have had a lot of trouble trying to build packages for NI Linux RT from a non-cRIO/native NI Linux RT environment and it would be a great help to be able to build packages for NI Linux RT without needing the NI hardware.

[j-medland]

Alas - no docs but I could probably write something up. I will try building this library and check that my previous experience wasn't just a fluke.

In the meantime, my docker build for a project that uses boost c++ libraries is here - https://gitlab.com/serenial/asynchronous-system-exec/-/tree/release/C++/docker-nilrt-build

The solution is very hand-rolled but it downloads, builds and installs all the tools required (GIT, CMake, opkg-tools) and then sets the environment as required to build using the NI-Toolchain.

I did find that the NI-Toolchain provided python executable (which lots of libraries use for configuration/build) was broken so I remove it and fallback to the system installed version and everything seemed to work.

[j-medland]

Just as an update -

I have been having a tinker and getting the cross-compile tools working for your SSH2 .ipkg build on x64 targets.

I was wondering if you would want to keep the current structure of multiple repositories for .ipkg which would lead to some duplication with build tooling or have one mega repo that builds all the packages?

On a related note: I had this exchange on Twitter and got pointed to this NI project that uses github actions to cross compile packages. I have never used github actions and I am unaware of the features/pricing but it could be interesting and determine if multi-repos is better or worse.

[volks73]

I was wondering if you would want to keep the current structure of multiple repositories for .ipkg which would lead to some duplication with build tooling or have one mega repo that builds all the packages?

I would like to keep them separate. The libssh2 shared library is not included in the default installation of NI's Linux Real-Time (RT) OS, nor is it provided as an additional package for installation from their official package repository. I could see applications and deployments that would want the libssh2 shared library but not the libssh2lv shared library.

However, I was thinking there could be a "meta" package that does include both libssh2 and libssh2lv, which would only require a single installation for all dependencies for the LabVIEW toolkit on NI Linux RT.

[volks73]

On a related note: I had this exchange on Twitter and got pointed to this NI project that uses github actions to cross compile packages. I have never used github actions and I am unaware of the features/pricing but it could be interesting and determine if multi-repos is better or worse.

I am just starting to use GitHub actions on another, non-LabVIEW, project. Thanks for sharing the links and discussion. I will look to combining this knowledge with my new GitHub Actions experience.