-- The C compiler identification is Clang 18.1.7 with GNU-like command-line
-- The CXX compiler identification is MSVC 19.29.30154.0
CMake Error at D:/bld/tudat_1718280535910/_build_env/Library/share/cmake-3.29/Modules/Platform/Windows-Clang.cmake:177 (message):
The current configuration mixes Clang and MSVC or some other CL compatible
compiler tool. This is not supported. Use either Clang or MSVC as the
compiler for all of C, C++, and/or HIP.
The hypothesis that the runner-image is to blame comes from the fact that, when retriggering a commit of the feedstock that was working previously, we get the exact compiler inconsistency error given above.
Why the compiler inconsistency between C and C++ happens is not clear, and I've tried various different changes to the feedstock to force the correct compilers to be used, but to no avail.
D:/bld/tudat_1719910775566/_h_env/Library/include\boost/config/auto_link.hpp:435:4: error: "Mixing a dll boost library with a static runtime is a really bad idea..."
435 | # error "Mixing a dll boost library with a static runtime is a really bad idea..."
| ^
D:/bld/tudat_1719910775566/_h_env/Library/include\boost/config/auto_link.hpp:485:4: error: "some required macros where not defined (internal logic error)."
485 | # error "some required macros where not defined (internal logic error)."
| ^
2 errors generated.
NMAKE : fatal error U1077: 'D:\bld\tudat_1719910775566\_build_env\Library\bin\clang++.exe -DCMAKE_BUILD_TYPE=Release -DTUDAT_BUILD_CLANG -DTUDAT_BUILD_WITH_ESTIMATION_TOOLS=1 -DTUDAT_BUILD_WITH_EXTENDED_PRECISION_PROPAGATION_TOOLS=0 -DTUDAT_BUILD_WITH_NRLMSISE=1 -DTUDAT_BUILD_WITH_PAGMO=0 -DTUDAT_BUILD_WITH_SOFA_INTERFACE=1 -D_ENABLE_EXTENDED_ALIGNED_STORAGE @CMakeFiles/test_aerodynamics_AerodynamicMomentAndAerodynamicForce.dir/includes_CXX.rsp -std=c++1z -Wall -Wextra -Wno-unused-parameter -Wno-unused-variable -Wno-unused-result -O3 -O3 -O3 -DNDEBUG -std=c++17 -MD -MT tests\src\astro\aerodynamics\CMakeFiles\test_aerodynamics_AerodynamicMomentAndAerodynamicForce.dir\unitTestAerodynamicMomentAndAerodynamicForce.cpp.obj -MF CMakeFiles\test_aerodynamics_AerodynamicMomentAndAerodynamicForce.dir\unitTestAerodynamicMomentAndAerodynamicForce.cpp.obj.d -o CMakeFiles\test_aerodynamics_AerodynamicMomentAndAerodynamicForce.dir\unitTestAerodynamicMomentAndAerodynamicForce.cpp.obj -c D:\bld\tudat_1719910775566\work\tests\src\astro\aerodynamics\unitTestAerodynamicMomentAndAerodynamicForce.cpp' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807\bin\HostX64\x64\nmake.exe" -s -f tests\src\astro\aerodynamics\CMakeFiles\test_aerodynamics_AerodynamicMomentAndAerodynamicForce.dir\build.make /nologo -SL tests\src\astro\aerodynamics\CMakeFiles\test_aerodynamics_AerodynamicMomentAndAerodynamicForce.dir\build' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807\bin\HostX64\x64\nmake.exe" -s -f CMakeFiles\Makefile2 /nologo -LS all' : return code '0x2'
Stop.
For reasons that are unclear to me, since no settings related to shared/static libraries were changed any time recently.
The above error only occurs when building the unit tests, and not when building the tudat libraries, in which case the compilation completes succesfully (-DTUDAT_BUILD_TESTS=0). But, in this case the tudatpy build using this tudat package fails, again due to a conflict between shared and static libraries.
To allow us to continue developing Tudat, and prevent this issue from cluttering up our builds, we'll be disabling the Windows build for now, until we have time to properly look into this, or hope for the runner images to be updated to resolve this (before anyone asks: no, to my knowledge it's not possible to use old runner images, boo!!!!)
But, Windows users need not worry! It's possible to use a Linux tudatpy kernel installed in WSL through your normal Windows PyCharm/VSCode IDE. Documentation on this will be added soon.
If anyone has ideas on how to fix this, please let us know!
We are disabling the Windows build, which is no longer compiling, presumably due to an update in the windows runner-image.
Last succesfull build: https://dev.azure.com/tudat-team/feedstock-builds/_build/results?buildId=1418&view=results Recent failing build: https://dev.azure.com/tudat-team/feedstock-builds/_build/results?buildId=1428&view=results
The underlying issue seems to be:
We know that this is not a 'fundamental' issue on Windows, since the Github Actions CI is compiling just fine (https://github.com/tudat-team/tudat/actions/runs/9740456962/job/26877611264#step:12:588), even though a unit tests is failing (but this is unrelated).
The hypothesis that the runner-image is to blame comes from the fact that, when retriggering a commit of the feedstock that was working previously, we get the exact compiler inconsistency error given above.
Why the compiler inconsistency between C and C++ happens is not clear, and I've tried various different changes to the feedstock to force the correct compilers to be used, but to no avail.
I've tried hard-coding the compiler as done here:
https://github.com/tudat-team/tudat-feedstock/commit/e4d2b16ca76a1655e93bdaeead00a3a9398b46e3
But this leads to (https://dev.azure.com/tudat-team/feedstock-builds/_build/results?buildId=1463&view=results):
For reasons that are unclear to me, since no settings related to shared/static libraries were changed any time recently.
The above error only occurs when building the unit tests, and not when building the tudat libraries, in which case the compilation completes succesfully (-DTUDAT_BUILD_TESTS=0). But, in this case the tudatpy build using this tudat package fails, again due to a conflict between shared and static libraries.
To allow us to continue developing Tudat, and prevent this issue from cluttering up our builds, we'll be disabling the Windows build for now, until we have time to properly look into this, or hope for the runner images to be updated to resolve this (before anyone asks: no, to my knowledge it's not possible to use old runner images, boo!!!!)
But, Windows users need not worry! It's possible to use a Linux tudatpy kernel installed in WSL through your normal Windows PyCharm/VSCode IDE. Documentation on this will be added soon.
If anyone has ideas on how to fix this, please let us know!