-
Notifications
You must be signed in to change notification settings - Fork 5
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
Cython build issues in combination with generated sources #31
Comments
The problem in both cases is missing files in the So: cp scipy/*.pxd build/scipy/
cp scipy/special/*.pxi build/scipy/special/
cp scipy/special/*.pxd build/scipy/special/
cp scipy/special/__init__.py build/scipy/special/
python scipy/linalg/_generate_pyx.py --outdir build
cp scipy/linalg/__init__.py build/scipy/linalg/ |
@Smit-create maybe one of these was your problem? If so, the workaround should help. |
I had the following error: $ meson setup build --prefix=$PWD/installdir
The Meson build system
Version: 0.58.1
Source dir: /home/smit/Smitlunagariya/scipy
Build dir: /home/smit/Smitlunagariya/scipy/build
Build type: native build
Project name: SciPy
Project version: 1.7.0.dev0+ababababab
Fortran compiler for the host machine: /home/smit/anaconda3/envs/scipy-dev/bin/x86_64-conda-linux-gnu-
gfortran (gcc 9.3.0 "GNU Fortran (crosstool-NG 1.24.0.133_b0863d8_dirty) 9.3.0")
Fortran linker for the host machine: /home/smit/anaconda3/envs/scipy-dev/bin/x86_64-conda-linux-gnu-gf
ortran ld.bfd 2.36.1
C compiler for the host machine: /home/smit/anaconda3/envs/scipy-dev/bin/x86_64-conda-linux-gnu-cc (gc
c 9.3.0 "x86_64-conda-linux-gnu-cc (crosstool-NG 1.24.0.133_b0863d8_dirty) 9.3.0")
C linker for the host machine: /home/smit/anaconda3/envs/scipy-dev/bin/x86_64-conda-linux-gnu-cc ld.bf
d 2.36.1
C++ compiler for the host machine: /home/smit/anaconda3/envs/scipy-dev/bin/x86_64-conda-linux-gnu-c++
(gcc 9.3.0 "x86_64-conda-linux-gnu-c++ (crosstool-NG 1.24.0.133_b0863d8_dirty) 9.3.0")
C++ linker for the host machine: /home/smit/anaconda3/envs/scipy-dev/bin/x86_64-conda-linux-gnu-c++ ld
.bfd 2.36.1
meson.build:1:0: ERROR: Tried to use unknown language "cython". When, I removed
|
Ah, that does mean you have an old version, it says you're using meson
or you can just clone the repo and locally run |
Some more failures in gh-76. Cause should be mesonbuild/meson#8961. |
This is starting to be urgent to fix. It continues to fail on the macOS CI job, and on Windows it needs Here is a simple explanation of the issue: scipy#14847 (comment) And a potential solution in Cython that I hadn't considered before: scipy#14847 (comment). |
Cython finds the module name from the path in a package here: https://github.com/cython/cython/blob/f372c5ab67c73a4c28e68e2aa8bee16a2ec0e4e1/Cython/Compiler/Main.py#L381
Generated C code will end up in a build dir, like at: The generated C code will contain the module name, like so: #define __Pyx_MODULE_NAME "scipy.special._ufuncs" If something goes wrong related to this issue, that name changes: #define __Pyx_MODULE_NAME "_ufuncs" A decent design would be to allow using |
@rgommers - I'm happy to have a go at that - let me know? |
That would be great, thanks @matthew-brett. I had just started looking into it, but I'm really short on time so would be great if you wanted to drive this one. Here's the full extent of my WIP patch, to save you about 5 minutes:
|
Thanks - will have a go at this tomorrow.
|
That looks neat. Since meson knows what the fully qualified module name is supposed to be -- using I will look forward to the opportunity to plug that prospective support into meson. |
It can be useful to specify the module name for the output file directly, rather than working it out from the enclosing file tree - particularly for out of tree build systems, like Meson. See: rgommers/scipy#31 (comment) for background.
Sketch at cython/cython#4548 |
It can be useful to specify the module name for the output file directly, rather than working it out from the enclosing file tree - particularly for out of tree build systems, like Meson. See: rgommers/scipy#31 (comment) for background.
It can be useful to specify the module name for the output file directly, rather than working it out from the enclosing file tree - particularly for out of tree build systems, like Meson. See: rgommers/scipy#31 (comment) for background.
I think this allows us to do something neat like https://github.com/matthew-brett/cyext/blob/main/meson.build . |
That'll be a very temporary thing right? We want support in Meson, and then |
Hmm - I hadn't registered how complex the Cython build was. Just for my reference, there are two issues for the source / build tree and Cython:
Here's a first sketch at respecifying a dependency. I believe it also correctly adds a |
I don't think I understand this. You cannot I suspect what you're seeing is that a |
Sorry - typing too quickly, and too late - I meant It is somewhat unrelated to that point, but yes, in testing, it turned out that the |
Ugh. Yes, you're right. We still need a fix for mesonbuild/meson#8961. |
What about splitting out the |
That should be fine. It won't solve everything, but it will solve this particular issue I suspect. |
I've done the split in scipy#15407 . I don't get any out-of-order errors now. I think I caught all the dependencies, but please do review. |
As discussed in rgommers#31 and Meson issue gh-8961, the current implementation for Cython (and maybe other) transpile steps means that we cannot specify dependencies that apply to the transpile (pyx -> c) step; dependencies only apply to the c building step. This in turn means it is possible to start a pyx -> c transpile without e.g. pxd or `__init__py` files in place, that Cython needs for module name discovery or `cimports`. This PR drops 'cython' as a project compiler, and splits all the Cython transpile steps out into separate steps prior to extension building. We can therefore add the transpile dependencies explicitly. I have tested a `ninja` `-j 1` compile, and several default compiles, without getting any of the Cython transpile errors we were getting before, without very high `-j` numbers.
Since this should now be fixed, I'll close it. I will add the upstream Meson issue to our tracking issue (gh-22), because we do want to get that fixed at some point, so we can simplify our |
It can be useful to specify the module name for the output file directly, rather than working it out from the enclosing file tree - particularly for out of tree build systems, like Meson. See background in rgommers/scipy#31 (comment)
It can be useful to specify the module name for the output file directly, rather than working it out from the enclosing file tree - particularly for out of tree build systems, like Meson. See background in rgommers/scipy#31 (comment) Backported-By: H. Vetinari <[email protected]>
Backport of #4548 It can be useful to specify the module name for the output file directly, rather than working it out from the enclosing file tree - particularly for out of tree build systems, like Meson. See background in rgommers/scipy#31 (comment)
There's multiple places where we can't express dependencies correctly, or we can but they go missing. I filed one issue upstream: mesonbuild/meson#8961.
Extensions that have problems:
scipy.special._ufuncs
scipy.linalg._decomp_update
If we build without expressing the dependency on
cython_blas.pxd
:And if we add it, that doesn't seem supported:
If we add all of
_generate_cy
as a dependency, then we rebuildcython_blas.pyx
andcython_lapack.pyx
which isn't right.optimize._lsq.givens_elimination
Not built yet, but also depends on
cython_lapack.pxd
The text was updated successfully, but these errors were encountered: