[Numpy-discussion] Quick question on NumPy builds vs. Cython
Wed Aug 26 01:14:21 CDT 2009
On Tue, Aug 25, 2009 at 9:44 PM, Charles R
> On Tue, Aug 25, 2009 at 11:30 AM, David Cournapeau <email@example.com>
>> Hi Dag,
>> On Tue, Aug 25, 2009 at 12:19 PM, Dag Sverre
>> Seljebotn<firstname.lastname@example.org> wrote:
>> > [Let me know if this should go to numpy-discuss instead.]
>> I guess this can be discussed on the ML as well (I CC to the list).
>> > I see that there are currently two modes, and that it is possible to
>> > build
>> > NumPy using a master .c-file #include-ing the rest. (Which is much more
>> > difficult to support using Cython, though not impossible.)
>> > Is there any plans for the one-file build to go away, or is supporting
>> > this
>> > a requirement?
>> This is a requirement, as supporting this depends on non standard
>> compilers extensions (that's why it is not the default - but it works
>> well, I am always using this mode when working on numpy since the
>> build/test/debug cycle is so much shorter with numscons and this).
>> The basic problem is as follows:
>> - On Unix at least, a function is exported in a shared library by
>> - The usual way to avoid polluting the namespace is to put static in
>> front of it
>> - You can't reuse a static function in another compilation unit
>> (there is no "friend static").
>> So what happens in the multi-files build is that the function are
>> tagged as hidden instead of static, with hidden being
>> __attribute__((hidden)) for gcc, nothing for MS compiler (on windows,
>> you have to tag the exported functions, nothing is exported by
>> default), and will break on other platforms.
> Does the build actually break or is it the case that a lot of extraneous
> names become visible, increasing the module size and exposing functions that
> we don't what anyone to access?
I think the latter. The number of exported symbols is pretty high, though.
More information about the NumPy-Discussion