[SciPy-dev] Re: [Numpy-discussion] Release of scipy core beta will happen next week.

[Robert Kern]

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
>> objects.
>>  
> 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...

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter