You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I was building python-control 0.10.2, I noticed a problem in the slycot build: the Windows runner was failing due to not being able to find nmake. I bypassed the issue by installing slycot from conda-forge, but wanted to point out so that whoever does the release knows it may be an issue.
Details (not much more than above) in python-control gh-1164.
I has been on my TODO list for ages to move from legacy scikit-build to either scikit-build-core or meson. That should overlap with rework of how to find the build tools and library headers. I'll see if I can get to it in the next couple days
the Windows runner was failing due to not being able to find nmake.
Something similar happened on fairly trivial PR I just submitted; I think the relevant problem is some issue with flang --- see end; after this CMake (I assume) goes on to try other MSVC versions and can't find nmake for them, so the final error messages are all about nmake.
move from legacy scikit-build to either scikit-build-core or meson.
That would be great.
I have access to a Windows 11 machine; I'll see how far I get with setting up a build environment. My past attempts at building Slycot on Windows have generally gone quite badly, however.
-- Check for working Fortran compiler: C:/Users/runneradmin/miniconda3/envs/build-env/conda-bld/slycot_1754230669354/_build_env/Library/bin/flang.exe - broken
CMake Error at C:/Users/runneradmin/miniconda3/envs/build-env/conda-bld/slycot_1754230669354/_build_env/Library/share/cmake-4.0/Modules/CMakeTestFortranCompiler.cmake:59 (message):
The Fortran compiler
"C:/Users/runneradmin/miniconda3/envs/build-env/conda-bld/slycot_1754230669354/_build_env/Library/bin/flang.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: 'C:/Users/runneradmin/miniconda3/envs/build-env/conda-bld/slycot_1754230669354/work/_cmake_test_compile/build/CMakeFiles/CMakeScratch/TryCompile-yslkbw'
Run Build Command(s): C:/Users/runneradmin/miniconda3/envs/build-env/conda-bld/slycot_1754230669354/_build_env/Library/bin/cmake.exe -E env VERBOSE=1 nmake -f Makefile /nologo cmTC_c3a8d\fast
"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\bin\HostX86\x64\nmake.exe" -f CMakeFiles\cmTC_c3a8d.dir\build.make /nologo -L CMakeFiles\cmTC_c3a8d.dir\build
Building Fortran object CMakeFiles/cmTC_c3a8d.dir/testFortranCompiler.f.obj
C:\Users\runneradmin\miniconda3\envs\build-env\conda-bld\slycot_1754230669354\_build_env\Library\bin\flang.exe -o CMakeFiles\cmTC_c3a8d.dir\testFortranCompiler.f.obj -c C:\Users\runneradmin\miniconda3\envs\build-env\conda-bld\slycot_1754230669354\work\_cmake_test_compile\build\CMakeFiles\CMakeScratch\TryCompile-yslkbw\testFortranCompiler.f
Linking Fortran executable cmTC_c3a8d.exe
C:\Users\runneradmin\miniconda3\envs\build-env\conda-bld\slycot_1754230669354\_build_env\Library\bin\cmake.exe -E vs_link_exe --msvc-ver=1900 --intdir=CMakeFiles\cmTC_c3a8d.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x86\rc.exe --mt="" --manifests -- C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1444~1.352\bin\Hostx86\x64\link.exe /nologo @CMakeFiles\cmTC_c3a8d.dir\objects1.rsp @C:\Users\RUNNER~1\AppData\Local\Temp\nm2550.tmp
Visual Studio Incremental Link with embedded manifests
Create CMakeFiles\cmTC_c3a8d.dir/manifest.rc
Create empty: CMakeFiles\cmTC_c3a8d.dir/embed.manifest
RC Pass 1:
C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x86\rc.exe /fo CMakeFiles\cmTC_c3a8d.dir/manifest.res CMakeFiles\cmTC_c3a8d.dir/manifest.rc
LINK Pass 1:
C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1444~1.352\bin\Hostx86\x64\link.exe /nologo @CMakeFiles\cmTC_c3a8d.dir\objects1.rsp /out:cmTC_c3a8d.exe /implib:cmTC_c3a8d.lib /pdb:C:\Users\runneradmin\miniconda3\envs\build-env\conda-bld\slycot_1754230669354\work\_cmake_test_compile\build\CMakeFiles\CMakeScratch\TryCompile-yslkbw\cmTC_c3a8d.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console /MANIFEST /MANIFESTFILE:CMakeFiles\cmTC_c3a8d.dir/intermediate.manifest CMakeFiles\cmTC_c3a8d.dir/manifest.res
LINK Pass 1: command "C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1444~1.352\bin\Hostx86\x64\link.exe /nologo @CMakeFiles\cmTC_c3a8d.dir\objects1.rsp /out:cmTC_c3a8d.exe /implib:cmTC_c3a8d.lib /pdb:C:\Users\runneradmin\miniconda3\envs\build-env\conda-bld\slycot_1754230669354\work\_cmake_test_compile\build\CMakeFiles\CMakeScratch\TryCompile-yslkbw\cmTC_c3a8d.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console /MANIFEST /MANIFESTFILE:CMakeFiles\cmTC_c3a8d.dir/intermediate.manifest CMakeFiles\cmTC_c3a8d.dir/manifest.res" failed (exit code 1104) with the following output:
LINK : fatal error LNK1104: cannot open file 'flangmain.lib'
NMAKE : fatal error U1077: 'C:\Users\runneradmin\miniconda3\envs\build-env\conda-bld\slycot_1754230669354\_build_env\Library\bin\cmake.exe -E vs_link_exe --msvc-ver=1900 --intdir=CMakeFiles\cmTC_c3a8d.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x86\rc.exe --mt="" --manifests -- C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1444~1.352\bin\Hostx86\x64\link.exe /nologo @CMakeFiles\cmTC_c3a8d.dir\objects1.rsp @C:\Users\RUNNER~1\AppData\Local\Temp\nm2550.tmp' : return code '0xffffffff'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\bin\HostX86\x64\nmake.exe" -f CMakeFiles\cmTC_c3a8d.dir\build.make /nologo -L CMakeFiles\cmTC_c3a8d.dir\build' : return code '0x2'
Stop.
After spending several hours each weekend since posting this issue on trying to get Windows + conda builds to work, I was midway between infuriated and amused to read a recent opinion that we, the Slycot maintainers, are "lazy" to be relying on conda builds of the package.
remove older Github workflow config for setting up Conda
get the right magic numbers in conda_build_config.yaml for MSVC and Fortran compilers,
choosing the right value for the FC environment variable
My proposal for 0.6.1 is to do the minimum changes to our Github config so we can pass a sane test matrix (3.10 to 3.14? that's the range I see at the slycot-feedstock PR), and look at scikit-build-core for the next release. I'm going to focus on getting Windows builds passing on this test matrix on my proof-of-concept branch; if that seems to work, I can make the necessary changes to a new, master-based branch and hopefully get everything building and passing.
gh-250 fixes conda builds, there seems to be a problems with coveralls on OSX. I ended up only building for 3.13, the latest release Python; each build results in 9 test cases (per Python version across all platforms; see set-conda-test-matrix.py).
FYI, I finally had a bit of time this weekend and started translating SLICOT to C. ilayn/SLICUTLET#1 is the main place to watch progress. It already has meson build scaffolding and provides bindings to Python and gets tested via pytest (already caught my own bugs). I also included some Fortran symbol mangling silliness to provide some convenience to link with MKL or other BLAS/LAPACK providers. ILP64 support is not so trivial so I left it for later.
I am not really planning at this stage the entire SLICOT to be translated as some of the routines are exceedingly niche but would be nice anyways. If there is interest I can prioritize the parts that python-control uses to package control a bit more uniformly on all C11 capable platforms.
All help feedback dis/encouragement is appreciated. Especially if you want to stretch some C programming muscles on a rainy weather it's more than welcome.
It is very practical in Python actually but there is always these folks complaining about performance. Plus I think it would be better to leave it in a state non-Python projects can also use. It is really not that hard really. Just very tedious. Because these are established parts of the control theory (the identification and controller synthesis notwithstanding, they are quite outdated).
Numerical linear algebra is not needed too much. Also the translations are quite mechanical. What I have been doing is translating them into C then creating an extension module for Python and asking LLM to write pytest compatible unit tests. That formula turns out to be quite productive as opposed to asking LLM to translate it which turned out to be not very fruitful.
A call for action is here ilayn/harold#102 😄 It is really a hobby project (in a straightjacket) really. We are almost done with the entire SciPy library F77 translations, and it has been running in production for the last 5 versions. So it gave me enough courage to attack SLICOT too.
If I can cover python-control parts, maybe it might ease your pain of releasing wheels. Obviously, feel free to decline, no hard feelings.
Activity
murrayrm commentedon Aug 2, 2025
When I was building python-control 0.10.2, I noticed a problem in the slycot build: the Windows runner was failing due to not being able to find
nmake. I bypassed the issue by installing slycot from conda-forge, but wanted to point out so that whoever does the release knows it may be an issue.Details (not much more than above) in python-control gh-1164.
bnavigator commentedon Aug 2, 2025
I has been on my TODO list for ages to move from legacy scikit-build to either scikit-build-core or meson. That should overlap with rework of how to find the build tools and library headers. I'll see if I can get to it in the next couple days
roryyorke commentedon Aug 3, 2025
Something similar happened on fairly trivial PR I just submitted; I think the relevant problem is some issue with
flang--- see end; after this CMake (I assume) goes on to try other MSVC versions and can't find nmake for them, so the final error messages are all about nmake.That would be great.
I have access to a Windows 11 machine; I'll see how far I get with setting up a build environment. My past attempts at building Slycot on Windows have generally gone quite badly, however.
roryyorke commentedon Sep 6, 2025
After spending several hours each weekend since posting this issue on trying to get Windows + conda builds to work, I was midway between infuriated and amused to read a recent opinion that we, the Slycot maintainers, are "lazy" to be relying on conda builds of the package.
Anyway, I have, at last, made progress.
I first tried converting to scikit-build-core (see https://github.com/roryyorke/Slycot/tree/rory/proto-scikit-core-build). This was relatively straightforward, and is an improvement --- but didn't sort out the Github Windows build.
Then, after many false starts, I got somewhere with our Windows build by taking a look at how https://github.com/conda-forge/slycot-feedstock gets it right --- there's a recentish PR there that has successful Windows builds. Copying from this I got the proof-of-concept https://github.com/roryyorke/Slycot/tree/rory/github-action-windows; a successful Windows build is at https://github.com/roryyorke/Slycot/actions/runs/17515691037 .
The important bits seem to have been
conda_build_config.yamlfor MSVC and Fortran compilers,FCenvironment variableMy proposal for 0.6.1 is to do the minimum changes to our Github config so we can pass a sane test matrix (3.10 to 3.14? that's the range I see at the slycot-feedstock PR), and look at scikit-build-core for the next release. I'm going to focus on getting Windows builds passing on this test matrix on my proof-of-concept branch; if that seems to work, I can make the necessary changes to a new, master-based branch and hopefully get everything building and passing.
bnavigator commentedon Sep 6, 2025
Sounds good to me. I spent some time with meson instead of scikit-build-core/cmake, but didn't get far.
moorepants commentedon Sep 6, 2025
You have to just ignore that nonsense.
roryyorke commentedon Sep 7, 2025
gh-250 fixes conda builds, there seems to be a problems with coveralls on OSX. I ended up only building for 3.13, the latest release Python; each build results in 9 test cases (per Python version across all platforms; see
set-conda-test-matrix.py).Proposed release notes below.
Fixes
Fixed a segmentation fault in ab09nd (gh-243).
Build
Conda build files updated from conda-forge/slycot-feedstock.
Testing
Fixes to Github Workflow CI.
Pull requests and issues associated with the release
PRs merged:
ruff checkwarnings; addruff checkto Github Actions #246 CI: add ruffIssues fixed:
Issues closed ("wont-fix"):
ilayn commentedon Oct 26, 2025
FYI, I finally had a bit of time this weekend and started translating SLICOT to C. ilayn/SLICUTLET#1 is the main place to watch progress. It already has meson build scaffolding and provides bindings to Python and gets tested via pytest (already caught my own bugs). I also included some Fortran symbol mangling silliness to provide some convenience to link with MKL or other BLAS/LAPACK providers. ILP64 support is not so trivial so I left it for later.
I am not really planning at this stage the entire SLICOT to be translated as some of the routines are exceedingly niche but would be nice anyways. If there is interest I can prioritize the parts that python-control uses to package control a bit more uniformly on all C11 capable platforms.
All help feedback dis/encouragement is appreciated. Especially if you want to stretch some C programming muscles on a rainy weather it's more than welcome.
roryyorke commentedon Nov 15, 2025
Interesting. Two questions:
roryyorke commentedon Nov 15, 2025
draft release at https://github.com/python-control/Slycot/releases/tag/untagged-3376af6f6e4c014bc6e6 - release notes have minor updates compared to what I put above.
ilayn commentedon Nov 15, 2025
A call for action is here ilayn/harold#102 😄 It is really a hobby project (in a straightjacket) really. We are almost done with the entire SciPy library F77 translations, and it has been running in production for the last 5 versions. So it gave me enough courage to attack SLICOT too.
If I can cover python-control parts, maybe it might ease your pain of releasing wheels. Obviously, feel free to decline, no hard feelings.
roryyorke commentedon Nov 16, 2025
I've published here, and pushed
sourcesdist to PyPI.For conda-forge: According to https://conda-forge.org/docs/maintainer/updating_pkgs/#pushing-to-regro-cf-autotick-bot-branch there should be an automatic process that will submit a PR for update. I'll leave this issue open until there's at least a PR, automatic or otherwise, on the feedstock repo.
moorepants commentedon Nov 16, 2025
Yes, a PR will open on the feedstock automatically.
moorepants commentedon Nov 16, 2025
There is also a new PR there to build with flang 21.
roryyorke commentedon Nov 22, 2025
All done! We may also get Python 3.14 + flang 21 builds on conda-forge, see feedstock repo for that.