MAINT: Replace numpy custom generation engine by raw C++ #19713
Conversation
serge-sans-paille
force-pushed
the
feature/to-cxx-and-beyond
branch
from
848d64f
to
bafb152
Compare
|
This looks great to me, but I don't know how easy it will be to get this working in our build system. |
serge-sans-paille
force-pushed
the
feature/to-cxx-and-beyond
branch
from
bafb152
to
a0a48ce
Compare
rgommers
added
the
C++
|
Interesting, thanks @serge-sans-paille!
It looks like it builds okay on Azure, there are just a few failures. On TravisCI I see:
Not sure what the exact problem is in Do you expect specific issues @eric-wieser? |
serge-sans-paille
force-pushed
the
feature/to-cxx-and-beyond
branch
from
a0a48ce
to
5016080
Compare
No, but I think I've seen build/distribution-issue-based resistance to switching to c++ before, and am merely expecting someone else to bring those up again. I don't know the details I'm afraid. |
|
Okay thanks. I think there are likely to be some fiddly details, but given that |
serge-sans-paille
force-pushed
the
feature/to-cxx-and-beyond
branch
from
5016080
to
a6982ad
Compare
We discussed that in one of the triage meetings and decided modern C++ was acceptable, @seiko2plus wanted it. |
serge-sans-paille
force-pushed
the
feature/to-cxx-and-beyond
branch
4 times, most recently
from
5cd48a6
to
d401263
Compare
|
All tests green except cygwin, and there's no error log so I can't track the error correctly, if some knows more than me about it ? |
serge-sans-paille
force-pushed
the
feature/to-cxx-and-beyond
branch
14 times, most recently
from
7dbc175
to
a9d5772
Compare
serge-sans-paille
force-pushed
the
feature/to-cxx-and-beyond
branch
8 times, most recently
from
3fa3dc5
to
3a59afd
Compare
This is just a technical prototype to measure and discuss the impact and implication of moving to C++ for kernel code generation.
serge-sans-paille
force-pushed
the
feature/to-cxx-and-beyond
branch
from
3a59afd
to
2ae7aeb
Compare
|
And all green again ;-) |
|
In the recent developer meeting, we decided to put this in as an experimental enhancement, without actually pushing to migrate the templated code to c++ templates for the 1.22 release. That way we can see if the infrastructure is solid before progressing. |
|
Thanks @serge-sans-paille |
charris
changed the title
|
🎉 |
In SciPy we had a couple of cases where we build a Python extension with C source files but linked against static libraries built from Fortran code. Those should be using the Fortran linker, but this was broken in 1.22.0 by numpygh-19713 (the PR that introduced C++ in NumPy). This fixes a few issues in the `build_ext` command, and documents better what is going on there. Should close SciPy issues 8325 and 15414.
In SciPy we had a couple of cases where we build a Python extension with C source files but linked against static libraries built from Fortran code. Those should be using the Fortran linker, but this was broken in 1.22.0 by numpygh-19713 (the PR that introduced C++ in NumPy). This fixes a few issues in the `build_ext` command, and documents better what is going on there. Should close SciPy issues 8325 and 15414.
This is just a technical prototype to measure and discuss the impact and
implication of moving to C++ for kernel code generation.