Add Windows builds to CI

[gavanderhoorn]

As the library does support Windows (see also #44, #70 and #91), it would be good to add Windows builds to the CI configuration.

industrial_ci will probably not be able to help, but we could look at other ROS (ROS2?) packages which have Windows builds as part of their CI and mimic their setup.

[gavanderhoorn]

I really don't use ROS on Windows, so this would not be something I would take on, unless I can more-or-less copy a configuration from somewhere else.

[traversaro]

Related docs on CI for ROS on Windows:

• https://ms-iot.github.io/ROSOnWindows/GettingStarted/SetupCI.html
• https://github.com/ms-iot/rosonwindows_ci

For non-ROS compilation, as mentioned in #70 (comment) it would be great to have a job for checking that case, it should be sufficient to have a simple GitHub Action like:

name: vcpkg Workflow

on:
  push:
  pull_request:
  schedule:
  # * is a special character in YAML so you have to quote this string
  # Execute a "nightly" build at 2 AM UTC 
  - cron:  '0 2 * * *'

jobs:
  build:
    name: 'vcpkg job'
    runs-on: windows-latest

    steps:
    - uses: actions/checkout@master
        
    - name: Install vcpkg Dependencies
      shell: bash
      run: |
        ${VCPKG_INSTALLATION_ROOT}/vcpkg.exe install --triplet x64-windows boost-asio boost-math boost-smart-ptr protobuf 

    - name: Build the project 
      shell: bash
      run: | 
        mkdir  build
        cd build
        cmake -DCMAKE_TOOLCHAIN_FILE=${VCPKG_INSTALLATION_ROOT}/scripts/buildsystems/vcpkg.cmake ..
        cmake --config Release --build .
        cmake --install .

For the non-ROS vcpkg case, I would be happy to open a PR.

[gavanderhoorn]

For the non-ROS vcpkg case, I would be happy to open a PR.

We can setup Actions here on this repository.

If you could submit a PR, that would be great.

[gavanderhoorn]

@traversaro: there is no real pressing need, but would you happen to have had a chance to take a look at the Windows CI setup?

[traversaro]

@traversaro: there is no real pressing need, but would you happen to have had a chance to take a look at the Windows CI setup?

Still on my todo list, Latest update was in #93, I did not investigate in details but it seems that the latest protobuf and/or CMake has some kind of problem in the producing the correct path of the generated headers when the .proto file is not in the same directory of the CMake script that invokes protobuf_generate_cpp . Probably we could bypass this problem by using ROSOnWindows also for CI (that ships a rather old protobuf version), but for our use the long term goal is to have abb_libegm that works fine with vcpkg provided dependencies.

[gavanderhoorn]

it seems that the latest protobuf and/or CMake has some kind of problem in the producing the correct path of the generated headers when the .proto file is not in the same directory of the CMake script that invokes protobuf_generate_cpp

Hm.

I seem to remember running into this myself.

We could create a sub CMakeLists.txt inside the proto dir, if that would help?

[traversaro]

We could create a sub CMakeLists.txt inside the proto dir, if that would help?

Actually that is explicitly not supported by FindProtobuf.cmake (unless the proto generated files are not moved in their own library, but I am not sure it is desirable), see https://cmake.org/cmake/help/v3.15/module/FindProtobuf.html :

The protobuf_generate_cpp and protobuf_generate_python functions and add_executable() or add_library() calls only work properly within the same directory.

[gavanderhoorn]

Hm. Blah.