Giter VIP home page Giter VIP logo

tudat-feedstock's People

Stargazers

 avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

tudat-feedstock's Issues

Re-enable Windows build

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:

-- 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.

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:

e4d2b16

But this leads to (https://dev.azure.com/tudat-team/feedstock-builds/_build/results?buildId=1463&view=results):

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!

Package conflicts with windows release

Currently there are issues regarding conflicts in packages with visual studio for the windows compilation. Windows has been removed temporarily while we move to this new deployment method as there is currently no testers for the 3.0 release that are using windows. Priority for this will be bumped up if windows users, who wish to test and contribute to suggestions, make themselves known on this issue. Check the CI history for appveyor builds for the conflict errors.

SPICE(FILENAMETOOLONG) in host environment with placeholder naming

================================================================================
Toolkit version: N0066
 
SPICE(FILENAMETOOLONG) --
 
Input file name </home/ggarrett/miniconda3/conda-bld/tudat_1592845536964/_h_env
_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold
_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold
_placehold_placehold_placehold_pl/resource/spice_kernels/pck00010.tpc> has
length 291 characters. The limit on the length of file names stored by FURNSH
is 255 characters.
 
A traceback follows.  The name of the highest level module is first.
furnsh_c --> FURNSH
 
Oh, by the way:  The SPICELIB error handling actions are USER-TAILORABLE.  You
can choose whether the Toolkit aborts or continues when errors occur, which
error messages to output, and where to send the output.  Please read the ERROR
"Required Reading" file, or see the routines ERRACT, ERRDEV, and ERRPRT.
 
================================================================================

By convention, conda build has historically used its placeholder naming. It's causing tests to break when loading kernels into spice, due to the 255 character limit with furnsh_c.

Following tests failing:

    - test_aerodynamics_AerodynamicMomentAndAerodynamicForce
    - test_aerodynamics_ControlSurfaceIncrements
    - test_aerodynamics_AerodynamicCoefficientsFromFile
    - test_aerodynamics_WindModel
    - test_spice_SpiceInterface
    - test_simulation_EnvironmentModelSetup
    - test_simulation_AccelerationModelSetup

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.