[Numpy-discussion] Should we drop support for "one file" compilation mode?
solipsis at pitrou.net
Tue Oct 6 13:27:53 EDT 2015
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
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
I'm thinking about the functions exposed in
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.
More information about the NumPy-Discussion