[SciPy-dev] Re: [Numpy-discussion] Release of scipy core beta will happen next week.
rkern at ucsd.edu
Mon Sep 26 19:48:15 CDT 2005
Travis Oliphant wrote:
> Robert Kern wrote:
>> * When linking umath.so, distutils is including a bare "-l" that causes
>> the link to fail (gcc can't interpret the argument). I have no idea
>> where it's coming from. Just after the Extension object for umath.so is
>> created, the libraries attribute is empty, just like the other Extension
> I've seen this too. It looks like scipy.distutils is detecting a
> "blank" mathlibs for OS X.
Got it. Fixed it.
>> Feature request:
>> * Bundle the include directory in with the package itself and provide a
>> function somewhere that returns the appropriate directory. People
>> writing setup.py scripts for extension modules that use scipy_core can
>> then do the following:
>> from scipy.distutils import get_scipy_include
>> someext = Extension('someext', include_dirs=[get_scipy_include(),
>> ...], ...)
> Sounds like a good idea. Not exactly sure how to do this. Anyone know??
arrayobject.h and ufuncobject.h are easy; just include them as data. For
the generated files, you only have to make some small modifications to
the generate_*() functions; instead of dropping them into the build_dir,
put them in the same directory as arrayobject.h and ufuncobject.h . I
have a patch. Unfortunately, it has a side-effect of including the
generated files in the sdist. We should be able to work around that by
making a MANIFEST.in .
With the caveat that this approach needs some more testing, I propose
that we stop installing headers with the install_header command and the
get_scipy_include() approach be the One Obvious Way To Do It. Comments?
I also have mtrand ready to go in. It isn't entirely plug-compatible
with RandomArray or RNG, but I think that it's clearly superior and
should be the *single* default PRNG in scipy_core (I emphasize *single*
because scipy.stats.ranf() is using one generator and the other
distributions are using another. This is not good.).
I have it as scipy.lib.mtrand at the moment. I haven't done anything to
integrate it with scipy.stats, yet. Should I check it in along with the
other fixes so people can play with it?
Actually, I should test whether or not I *have* checkin privileges...
rkern at ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
More information about the Scipy-dev