[Numpy-discussion] Quick question on NumPy builds vs. Cython

Charles R Harris charlesr.harris@gmail....
Tue Aug 25 21:44:41 CDT 2009


On Tue, Aug 25, 2009 at 11:30 AM, David Cournapeau <cournape@gmail.com>wrote:

> Hi Dag,
>
> On Tue, Aug 25, 2009 at 12:19 PM, Dag Sverre
> Seljebotn<dagss@student.matnat.uio.no> 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 default.
>  - 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?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20090825/46e93043/attachment.html 


More information about the NumPy-Discussion mailing list