I have a very simple project that indicate that when in Windows (Linux) CMAKE_CXX_SOURCE_RUNS is calling (is not calling) my macro check_source_runs. The commands
mkdir build
cd build
cmake ..
run fine on Linux and exit with an error in Windows. The error is the FATAL_ERROR in the check_soruce_runs macro. I am using a Visual Studio 2019 command shell to run cmake on windows.
Here is my CMakeLIsts.txt file:
PROJECT(test)
CMAKE_MINIMUM_REQUIRED(VERSION 3.0)
INCLUDE(CheckCXXSourceRuns)
INCLUDE( check_source_runs.cmake )
SET(source_code "
int main(void)
{ return 0;
}")
CHECK_CXX_SOURCE_RUNS( "${source_code}" flag )
Here is my file check_source_runs.cmake
MACRO( check_source_runs )
MESSAGE(FATAL_ERROR "The check_source_runs macro is being called by CHECK_CXX_SOURCE_RUNS")
ENDMACRO( check_source_runs )
Can you confirm the CMake version that gets invoked on Windows and on Linux? Have your project actually print it by adding the following line:
message("CMake version = ${CMAKE_VERSION}")
I can’t think of a reason why the behavior would be different between platforms (assuming no subtle bug to do with case sensitivity of the file system making a difference).
As an aside, the cmake_minimum_required() command should come before the call to project(). The cmake_minimum_required() command sets some policies that will/should affect the call to project().
I kept CMakeLists.txt and check_source_runs.cmake the same, I just added a request for the cmake version on the command line. Here is the verbose output on Linux:
if [ -e build ]
then
rm -r build
fi
mkdir build
cd build
cmake --version
cmake version 3.14.5
CMake suite maintained and supported by Kitware (kitware.com/cmake).
cmake ..
-- The C compiler identification is GNU 9.2.1
-- The CXX compiler identification is GNU 9.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- 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: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test flag
-- Performing Test flag - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /home/bradbell/trash/cmake_bug/build
cd ..
rm -r build
#
echo 'run.sh: OK'
run.sh: OK
exit 0
Here is the verbose output on Windows:
C:\msys64\home\bradl\trash\cmake_bug>IF EXIST build RMDIR /S /Q build
C:\msys64\home\bradl\trash\cmake_bug>MKDIR build
C:\msys64\home\bradl\trash\cmake_bug>CD build
C:\msys64\home\bradl\trash\cmake_bug\build>cmake --version
cmake version 3.19.0-rc1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
C:\msys64\home\bradl\trash\cmake_bug\build>cmake …
– Building for: Visual Studio 16 2019
– Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.18363.
– The C compiler identification is MSVC 19.27.29112.0
– The CXX compiler identification is MSVC 19.27.29112.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/Community/VC/Tools/MSVC/14.27.29110/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/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe - skipped
– Detecting CXX compile features
– Detecting CXX compile features - done
CMake Error at check_source_runs.cmake:2 (MESSAGE):
The check_source_runs macro is being called by CHECK_CXX_SOURCE_RUNS
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.19/Modules/CheckCXXSourceRuns.cmake:71 (check_source_runs)
CMakeLists.txt:9 (CHECK_CXX_SOURCE_RUNS)
-- Configuring incomplete, errors occurred!
See also "C:/msys64/home/bradl/trash/cmake_bug/build/CMakeFiles/CMakeOutput.log".
C:\msys64\home\bradl\trash\cmake_bug\build>cd ..
C:\msys64\home\bradl\trash\cmake_bug>RMDIR /S /Q build
C:\msys64\home\bradl\trash\cmake_bug>REM
C:\msys64\home\bradl\trash\cmake_bug>ECHO 'run.bat: OK'
'run,bat: OK'
You are using different CMake versions on the two different platforms. The 3.19 release is the first one where check_cxx_source_runs() forwards to check_source_runs(). This is why you are not seeing your check_source_runs() macro being invoked on Linux, since you are only running 3.14 there. I posted just yesterday about updating the 3.19 docs for these modules, which I suspect would make situations like this a bit clearer.
So this is a change to to API for check_cxx_source_runs; i.e., it is not backward compatible ?
I would expect the major version of cmake to change when the API was no longer backward compatible. Are there at least release notes that list all of these sort of changes ?
No it is not an API change. The original API of the commands from the various Check<Lang>SourceRuns modules should still be honoured. What seems to be the case here is you are trying to use an implementation detail of the new module introduced in CMake 3.19 and expect it to work with an older CMake version. You should also not be trying to hijack the check_source_runs() command by replacing it with your own.
I am not trying to use the implementation detail. My original check_source_runs macro was a wrapper for CHECK_CXX_SOURCE_RUNS. I do not see any mention in https://cmake.org/cmake/help/latest/module/CheckCXXSourceRuns.html
of the fact that the name check_source_runs cannot be used for such a purpose.
I agree that automatic capture of the check_source_runs names without explicit opt-in by including the name CheckSourceRuns module shouldn’t happen.
I think that we can do is move the implementation to cmake_check_source_runs and only have that exposed when including files such as CheckCXXSourceRuns. This will better preserve backwards compatibility as CMake reserves all functions starting with cmake_.
I should have time this week to open a merge request to fix this.