-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
building sdist fails with CMake subproject #668
Comments
After naive searches for |
@eli-schwartz do you have the permission to transfer this issue to the other repo? (if that looks like the right idea here?) |
The stack trace points to the code in meson-python that cleans up the temporary build directory, thus this does not look to be a meson issue. However, I do not have any idea of what is keeping files in the build directory busy, except something related to meson. Windows is so weird in this regard that I don't even know where to start looking and I don't have easy access to a system where I can test this. Someone would need to debug this. EDIT: The interesting part of the stack trace has been cut off from the report, but it is available in the CI log. Here is the whole thing:
|
oops, thanks for catching the full traceback! I've edited the top post |
If I understand you correctly, it looks like a process related to building the CMake subproject introduced in that PR:
|
Not building but just configuring. Sub-projects are not build, only configured, to create an sdist. I saw the path in the stack trace. But I have no idea what may keep that file busy. The only process executed by meson-python is meson. And meson is a single process Python application, thus parts of it are for sure not lingering around. For configuring a CMake subproject, meson executes cmake, but I'm pretty sure it waits for the child process to exit before continuing. Thus it is either a process started by CMake that stays around, or it is some weird Windows thing where something interposes between the process opening the file and the filesystem. |
Well, cmake's normal means of operation when configuring a cmake build, is for the cmake equivalent of meson's This may be a recursion issue -- but I have no idea what or how cmake waits on its own subprocesses. Perhaps a sub-cmake is still lingering? CMakeScratch is a definite red flag though because a directory filename as specific as that is absolutely 100% a cmake internal and meson doesn't touch it either. And cmake claims it cleans that up automatically as part of its own configure stage before exiting. |
@mwoehlke-kitware I noticed that you touched the following lines. Perhaps you could shed some light here? https://github.com/Kitware/CMake/blob/master/Help/command/try_compile.rst#L120-L125 |
I don't see how this has anything to do with the change cited? I'm not at all a Windows expert, but I do seem to recall running into files "locked" by the OS longer than you'd expect is a thing that can happen when compiling code. Maybe try asking on a more general CMake forum, especially one that gets more Windows users? |
thanks for the quick response! will do |
@eli-schwartz would you be able to tell me what call meson makes to cmake so that I can report the potential problem on their side? |
I can look for this information later tonight. But off the top of my head I think we're supposed to log the exact call in the debug log... |
I tried to build an sdist locally on windows to access a debug log here but I wasn't able to set up compilers correctly - building SciPy on windows can be a bit of a nightmare. |
This seems to have resolved itself?! Has anything changed on the meson side in relation to this as far as you know @eli-schwartz ? |
As far as I'm aware nothing has changed on the meson side. How mysterious... |
Traceback:
Full log: https://github.com/scipy/scipy/actions/runs/10884814141/job/30200964434?pr=21270
x-ref scipy/scipy#21270
The text was updated successfully, but these errors were encountered: