Ask Your Question
0

Ros1 melodic on Windows catkin_make fails on empty workspace

asked 2020-04-20 14:27:39 -0600

bwolfe gravatar image

After installing ROS1 on Windows, I created a workspace with src directory in it. Within that workspace directory, a catkin_make fails as follows:

d:\Projects\ros1_ws>catkin_make
Base path: d:\Projects\ros1_ws
Source space: d:\Projects\ros1_ws\src
Build space: d:\Projects\ros1_ws\build
Devel space: d:\Projects\ros1_ws\devel
Install space: d:\Projects\ros1_ws\install
Copying file from "C:\opt\ros\melodic\x64\share\catkin\cmake\toplevel.cmake" to "d:\Projects\ros1_ws\src\CMakeLists.txt"####
#### Running command: "cmake d:\Projects\ros1_ws\src -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCATKIN_DEVEL_PREFIX=d:\Projects\ros1_ws\devel -DCMAKE_INSTALL_PREFIX=d:\Projects\ros1_ws\install -G NMake Makefiles" in "d:\Projects\ros1_ws\build"
####
CMake Warning (dev) in CMakeLists.txt:
  No project() command is present.  The top-level CMakeLists.txt file must
  contain a literal, direct call to the project() command.  Add a line of
  code such as

    project(ProjectName)

  near the top of the file, but after cmake_minimum_required().

  CMake is pretending there is a "project(Project)" command on the first
  line.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Check for working C compiler: C:/MinGW/bin/gcc.exe
-- Check for working C compiler: C:/MinGW/bin/gcc.exe - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/MinGW/bin/g++.exe
-- Check for working CXX compiler: C:/MinGW/bin/g++.exe - works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using CATKIN_DEVEL_PREFIX: D:/Projects/ros1_ws/devel
-- Using CMAKE_PREFIX_PATH: C:/opt/ros/melodic/x64;C:/opt/rosdeps/x64;C:/opt/vcpkg/installed/x64-windows
-- This workspace overlays: C:/opt/ros/melodic/x64
-- Found PythonInterp: C:/opt/python27amd64/python.exe (found suitable version "2.7.15", minimum required is "2")
-- Using PYTHON_EXECUTABLE: C:/opt/python27amd64/python.exe
-- Using default Python package layout
CMake Warning (dev) at C:/opt/python27amd64/Lib/site-packages/cmake/data/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272 (message):
  The package name passed to `find_package_handle_standard_args` (PY_em) does
  not match the name of the calling package (catkin).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  C:/opt/ros/melodic/x64/share/catkin/cmake/empy.cmake:20 (find_package_handle_standard_args)
  C:/opt/ros/melodic/x64/share/catkin/cmake/empy.cmake:27 (find_python_module)
  C:/opt/ros/melodic/x64/share/catkin/cmake/all.cmake:164 (include)
  C:/opt/ros/melodic/x64/share/catkin/cmake/catkinConfig.cmake:20 (include)
  CMakeLists.txt:56 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found PY_em: C:\opt\python27amd64\lib\site-packages\em.pyc
-- Using empy: C:/opt/python27amd64/lib/site-packages/em.pyc
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: D:/Projects/ros1_ws/build/test_results
-- Found gtest: gtests will be built
-- Using Python nosetests: C:/opt/python27amd64/Scripts/nosetests-2.7 ...
(more)
edit retag flag offensive close merge delete

Comments

@bwolfe, I noticed that it is using MinGW toolchain. Can you run the ROS command prompt with the MSVC toolchain? You can find it at step no.6 here: http://wiki.ros.org/Installation/Windows

Sean Yen gravatar image Sean Yen  ( 2020-04-20 15:14:02 -0600 )edit

It's not obvious how I would switch to using the MSVC tool chain.

bwolfe gravatar image bwolfe  ( 2020-04-20 15:35:24 -0600 )edit

The toolchain used is inherited by the batch file which starts the command window, specifically the visual studio x64 build window. If you have MinGW in your system path it should be removed so that the command window doesn't get tainted by an incompatible compiler.

OoeyGUI gravatar image OoeyGUI  ( 2020-04-20 17:12:25 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2020-04-21 07:23:00 -0600

bwolfe gravatar image

Thanks to Sean Yen and OoeyGUI (clever!) suggestions, I removed mingw from my path, but that alone actually broke the compiler chain altogether. The solution was to also clear/delete the environment variable definitions for CC and CXX, which causes VS to use its default compiler tools.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

3 followers

Stats

Asked: 2020-04-20 14:27:39 -0600

Seen: 298 times

Last updated: Apr 21 '20