ros-tooling/action-ros-ci

Windows build environment fails to propagate to CMake external project

christophebedard opened this issue · 5 comments

Description

https://github.com/ament/uncrustify_vendor uses a CMake external project (uncrustify).

Expected Behavior

Builds fine on Windows.

Actual Behavior

Fails to build on Windows. It fails when CMake checks for C and CXX compilers. The vendor CMake project can find the compiler just fine, but the external project cannot.

  --- output: uncrustify_vendor
  -- The C compiler identification is MSVC 19.28.29914.0
  -- The CXX compiler identification is MSVC 19.28.29914.0
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.28.29910/bin/Hostx64/x64/cl.exe - skipped
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.28.29910/bin/Hostx64/x64/cl.exe - skipped
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Found ament_cmake: 1.1.4 (D:/a/rmw_cyclonedds/rmw_cyclonedds/ros_ws/install/ament_cmake/share/ament_cmake/cmake)
  -- Found PythonInterp: C:/hostedtoolcache/windows/Python/3.7.9/x64/python3.exe (found suitable version "3.7.9", minimum required is "3") 
  -- Using PYTHON_EXECUTABLE: C:/hostedtoolcache/windows/Python/3.7.9/x64/python3.exe
  -- Configuring done
  -- Generating done
  -- Build files have been written to: D:/a/rmw_cyclonedds/rmw_cyclonedds/ros_ws/build/uncrustify_vendor
  Microsoft (R) Build Engine version 16.9.0+5e4b48a27 for .NET Framework
  
  Copyright (C) Microsoft Corporation. All rights reserved.
  
  
  
    Checking Build System
  
    Creating directories for 'uncrustify-45b836cff040594994d364ad6fd3f04adc890a26'
  
    Performing download step (git clone) for 'uncrustify-45b836cff040594994d364ad6fd3f04adc890a26'
  
    Cloning into 'uncrustify-45b836cff040594994d364ad6fd3f04adc890a26'...
  
    HEAD is now at 45b836cf Merge pull request #2308 from emersonknapp/md5-armhf
  
    No update step for 'uncrustify-45b836cff040594994d364ad6fd3f04adc890a26'
  
    Performing patch step for 'uncrustify-45b836cff040594994d364ad6fd3f04adc890a26'
  
    Performing configure step for 'uncrustify-45b836cff040594994d364ad6fd3f04adc890a26'
  
    -- The C compiler identification is unknown
  
    -- The CXX compiler identification is unknown
  
    -- Configuring incomplete, errors occurred!
  
    See also "D:/a/rmw_cyclonedds/rmw_cyclonedds/ros_ws/build/uncrustify_vendor/uncrustify-45b836cff040594994d364ad6fd3f04adc890a26-prefix/src/uncrustify-45b836cff040594994d364ad6fd3f04adc890a26-build/CMakeFiles/CMakeOutput.log".
  
    See also "D:/a/rmw_cyclonedds/rmw_cyclonedds/ros_ws/build/uncrustify_vendor/uncrustify-45b836cff040594994d364ad6fd3f04adc890a26-prefix/src/uncrustify-45b836cff040594994d364ad6fd3f04adc890a26-build/CMakeFiles/CMakeError.log".
  
    CMake Error at CMakeLists.txt:3 (project):
  
      No CMAKE_C_COMPILER could be found.

    CMake Error at CMakeLists.txt:3 (project):
  
      No CMAKE_CXX_COMPILER could be found.

See: https://github.com/ros2/rmw_cyclonedds/runs/2522103892#step:6:3605

To Reproduce

Build uncrustify_vendor on Windows, e.g.

    - uses: ros-tooling/setup-ros@master
    - uses: ros-tooling/action-ros-ci@master
      with:
        package-name: uncrustify_vendor
        vcs-repo-file-url: https://raw.githubusercontent.com/ros2/ros2/master/ros2.repos

For a full example, see rmw_cyclonedds's CI config: https://github.com/ros2/rmw_cyclonedds/blob/2bbc260b987523b131fd8f5bbc002d5fc9801e0b/.github/workflows/CI.yml

System

  • OS: Windows
  • ROS 2 Distro: Rolling (possibly any other recent distro)

Additional context

I think that action-ros-ci's Windows build environment might not be correctly set up. We're running some scripts along with each command on Windows (to setup the build environment?), but maybe it doesn't properly propagate:

if (isWindows) {
toolRunnerCommandLine = "C:\\Windows\\system32\\cmd.exe";
// This passes the same flags to cmd.exe that "run:" in a workflow.
// https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#using-a-specific-shell
// Except for /D, which disables the AutoRun functionality from command prompt
// and it blocks Python virtual environment activation if one configures it in
// the previous steps.
toolRunnerCommandLineArgs = [
"/E:ON",
"/V:OFF",
"/S",
"/C",
"call",
"%programfiles(x86)%\\Microsoft Visual Studio\\2019\\Enterprise\\VC\\Auxiliary\\Build\\vcvarsall.bat",
"amd64",
"&",
"C:\\Program Files\\Git\\bin\\bash.exe",
"-c",
bashScript,
];
This is similar to how ci.ros2.org does it, but it's not exactly the same.

I tried to pass -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER} and -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER} as CMAKE_ARGS to ExternalProject_Add but it doesn't do much.

Are you able to actually get any Windows builds working using action-ros-ci? I tried to enable a test of that at #630 and failed - maybe I'm missing something.

It seems to work in some situations (e.g. Python packages and maybe simple C++ packages?), but overall it doesn't work well 😕

I was trying to enable windows builds with action-ros-ci too and couldn't get builds to work. I replicated the commands the action calls locally and think i found the issue.

C:\Windows\system32\cmd.exe /E:ON /V:OFF /S /C call "%programfiles(x86)%\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" amd64 & "C:\Program Files\Git\bin\bash.exe" -c "c:/dev/foxy/ros2-windows/setup.bat && colcon build --event-handlers console_cohesion+" calls the setup.bat script from within a gitbash shell. the resulting environment doesn't have the required environment variables set and causes issues with finding cmake configs, etc: https://github.com/wmmc88/test-repo/runs/3713014678?check_suite_focus=true

ill try to submit a fix for it

with #712 and #719 merged, i think this is resolved?

Yep! I opened #725 for the testing part.