scikit-build
fix: Improve python lib detection
On windows the vars in sysconfig return None so as a fallback we try to enumerate possible library candidates in the installation base to see if we can find the library
This change get's rid of the following warning
2025-05-31 23:15:15,755 - scikit_build_core - WARNING - Can't find a Python library, got libdir=None, ldlibrary=None, multiarch=None, masd=None
2025-05-31 23:15:15,755 - scikit_build_core - WARNING - Can't find a Python library, got libdir=None, ldlibrary=None, multiarch=None, masd=None
For the lib part Python_ROOT_DIR and FindPython should handle that fallback logic. I actually am not sure why include hint is passed, but in that case it is directly exposed in the sysconfig.
For the lib part
Python_ROOT_DIRandFindPythonshould handle that fallback logic. I actually am not sure why include hint is passed, but in that case it is directly exposed in thesysconfig.
Pushed the fix just noticed in the get_library function if abi3=True we don't look for the .lib with minor version
I thought that the original issue was more about what library variant gets detected and what gets reported by python3-conf (forgot what the name of the shell script is). @henryiii can clarify the issue? I believe that if we do such library guess work we are not much different than how FindPython works it out?
One key thing is that FindPython has 2 modes of detection based on if Interpreter is passed or not [^1] and if the CMake module is inconsistent depending on this, we should pass the helper to override that.
[^1]: somewhere around here: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/FindPython/Support.cmake?ref_type=heads#L581
The reason I didn't add this yet was I felt the old logic just tried "everthing possible", and wanted a more principled approach. Hard-coding things like pypy means this might miss graalpy, for example. It seems like "where's the library" shouldn't be that hard of question. But I added printouts for libdir=None, ldlibrary=None, multiarch=None, masd=None, and they are all None on Windows, so this is probably what we'll have to do.
Have you looked at the logic in CMake's FindPython? That's been good, replicating that is likely ideal.
There are two concerns; the one voiced above, with running into a new situtation like a new interpreter implementation, and the the other is cross-compiling. We might end up picking up a completely incorrect library if we try to hunt too hard.
I'll try to carefully review soon, I've been distracted with pybind11 3.0 and cibuildwheel 3.0 release preparations, and I'm teaching a summer course.
