[Numpy-discussion] Linker script, smaller source files and symbol visibility

[David Cournapeau]

Charles R Harris wrote:
 
>
> Here is a link to the start of the old discussion
> <http://article.gmane.org/gmane.comp.python.numeric.general/12974/match=exported+symbols+code+reorganization>.
> You took part in it also.

Thanks, I remembered we had the discussion, but could not find it. The
different is that I am much more familiar with the technical details and
numpy codebase now :) I know how to control exported symbols on most
platform which matter (I can't test for AIX or HP-UX unfortunately - but
I am perfectly fine with ignoring namespace pollution on those anyway),
and I would guess that the only platforms which do not support symbol
visibility in one way or the other do not support shared library anyway
(some CRAY stuff, for example).

Concerning the file size, I don't think anyone would disagree that they
are too big, but we don't need to go the "java-way" of one
file/class-function either. One first split which I personally like is
API/implementation. For example, for multiarray.c, we would only keep
the public PyArray_* functions, and put everything else in another file.
The other very big file is arrayobject.c, and this one is already mostly
organized in independent parts (buffer protocol, number protocol, etc...)

Another thing I would like to do it to make the global C API array
pointer a 'true' global variable instead of a static one. It took me a
while when I was working on the hashing protocol for dtype to understand
why it was crashing (the array pointer being static, every file has its
own copy, so it was never initialized in the hashdescr.c file). I think
a true global variable, hidden through a symbol map, is easier to
understand and more reliable.

cheers,

David