Fix glibc dependency (too hight)

[thomasarsouze]

No description provided.

[AurelienBesnier]

Hi, I think the ci on windows fails because it tries to use visual studio instead of mingw maybe it gets overwritten. You might need to change the generator to MinGW Makefiles

[thomasarsouze]

You're right. We said we need to use visual studio for the next release, so we need to get rid of MinGW Makefiles

[AurelienBesnier]

Maybe removing the conda_build_config.yaml would help.

It's also possible we have to set it inside the CMakeLists.txt like this:

set(CMAKE_GENERATOR "Visual Studio 18 2026")

or maybe set the version of the toolset like this:

set(CMAKE_GENERATOR_TOOLSET "version=14.51")  # or whatever the version is 

It should also be possible to pass those variables like it was done before in the meta.yaml

[thomasarsouze]

Maybe removing the conda_build_config.yaml would help.

It's also possible we have to set it inside the CMakeLists.txt like this:

set(CMAKE_GENERATOR "Visual Studio 18 2026")

It looks like 'windows-latest' runner has recently changed to use VS2026 as default, and not VS2022 as used by conda-forge... I'll change windows runner to 'windows-2022'

or maybe set the version of the toolset like this:

set(CMAKE_GENERATOR_TOOLSET "version=14.51")  # or whatever the version is 

It should also be possible to pass those variables like it was done before in the meta.yaml

I keep investigating solutions where I do not have to set versions whether in pyproject, meta of cmake files.

[GeraultTr]

Hello, I just edited the definition of HUGE for windows-2022 so it aligns with linux and mac and eventually enable to pass the CI. I think the fix is still relevant if going back to windows-latest.

[AurelienBesnier]

The fix for mac is also being worked on in this PR #14. It's a path problem