[Numpy-discussion] Should we drop support for "one file" compilation mode?
cournape at gmail.com
Tue Oct 6 12:56:50 EDT 2015
On Tue, Oct 6, 2015 at 5:51 PM, David Cournapeau <cournape at gmail.com> wrote:
> On Tue, Oct 6, 2015 at 5:44 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> On Tue, Oct 6, 2015 at 4:46 AM, David Cournapeau <cournape at gmail.com>
>> > The npy_ functions in npymath were designed to be exported. Those would
>> > that way.
>> If we want to export these then I vote that we either:
>> - use the usual API export mechanism, or else
>> - provide a static library for people to link to, instead of trying to
>> do runtime binding. (I.e. drop it in some known place, and then
>> provide some functions for extension modules to find it at build time
>> -- similar to how np.get_include() works.)
> Unless something changed, that's more or less how it works already
> (npymath is used in scipy, for example, which was one of the rationale for
> writing it in the first place !).
> You access the compilation/linking issues through the numpy distutils
> get_info function.
And my suggestion is to use a similar mechanism for multiarray and umath,
so that in the end the exported Python C API is just a thin layer on top of
the underlying static library. That would make cython and I suspect static
linking quite a bit easier. The API between the low layer and python C API
of multiarray/umath would be considered private and outside any API/ABI
IOW, it would be an internal change, and should not cause visible changes
to the users, except that some _npy_private_ symbols would be exported (but
you would be crazy to use them, and the prototype declarations would not be
available when you install numpy anyway). Think of those as the internal
driver API/ABI of Linux or similar.
>> Nathaniel J. Smith -- http://vorpus.org
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion