[Numpy-discussion] reorganizing numpy internal extensions (was: Re: Should we drop support for "one file" compilation mode?)

[Nathaniel Smith]

On Oct 8, 2015 06:30, "David Cournapeau" <cournape at gmail.com> wrote:
>
[...]
>
> Separating the pure C code into static lib is the simple way of achieving
the same goal. Essentially, you write:
>
> # implemented in npyinternal.a
> _npy_internal_foo(....)
>
> # implemented in merged_multiarray_umath.pyx
> cdef PyArray_Foo(...):
>     # use _npy_internal_foo()
>
> then our merged_multiarray_umath.so is built by linking the .pyx and the
npyinternal.a together. IOW, the static link is internal.
>
> Going through npyinternal.a instead of just linking .o from pure C and
Cython together gives us the following:
>
>  1. the .a can just use normal linking strategies instead of the awkward
capsule thing. Those are easy to get wrong when using cython as you may end
up with multiple internal copies of the wrapped object inside capsule,
causing hard to track bugs (this is what we wasted most of the time on w/
Stefan and Kurt during ds4ds)

Check out Stéfan's branch -- it just uses regular linking to mix cython and
C. I know what you mean about the capsule thing, and I think we shouldn't
use it at all. With a few tweaks, you can treat cython-generated .c files
just like regular .c files (except for the main module file, which if we
port it to cython then we just compile like a regular cython file).

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20151008/7459cf1e/attachment.html>