[Numpy-discussion] Should we drop support for "one file" compilation mode?

[Antoine Pitrou]

On Tue, 6 Oct 2015 10:07:13 -0700
Nathaniel Smith <njs at pobox.com> wrote:
> 
> And how are you getting at them? Are you just relying the way that on
> ELF systems, if two libraries are loaded into the same address space
> then they automatically get access to each other's symbols, even if
> they aren't linked to each other? What do you do on Windows?

Well it seems to work on Windows too, thanks to
numpy.distutils.misc_util.get_info('npymath').

Under Windows, I seem to have a
"<Python root>\site-packages\numpy\core\lib\npymath.lib" static library,
and there's also a "npy-pkg-config" subdirectory there with some INI
files in it.  Hopefully you know better than me what this all is :-)

> > And, of course, we would also benefit from the CBLAS functions (or any
> > kind of C wrappers around them) :-)
> > https://github.com/numpy/numpy/issues/6324
> 
> This is difficult to do from NumPy itself -- we don't necessarily have
> access to a full BLAS or LAPACK API -- in some configurations we fall
> back on our minimal internal implementations that just have what we
> need.

I'm thinking about the functions exposed in
"numpy/core/src/private/npy_cblas.h".
My knowledge of the Numpy build system doesn't allow me to tell if it's
always available or not :-)

> There was an interesting idea that came up in some discussions here a
> few weeks ago -- we already know that we want to package up BLAS
> inside a Python package that (numpy / scipy / scikit-learn / ...) can
> depend on and assume is there to link against.
> 
> Maybe this new package would also be a good place for exposing these wrappers?

Yeah, why not - as long as there's something well-known and
well-supported to depend on.  But given Numpy is a hard dependency for
all the other packages you mentioned, it may make sense (and simplify
dependency management) to bundle it with Numpy.

Regards

Antoine.