On 24 February 2010 18:58, Greg Ewing <[email protected]> wrote: > Lisandro Dalcin wrote: > >> Greg, I would love to have some input from your side. This is >> something where Pyrex and Cython should agree (probably by following >> recommended, documented practices in core CPython).
> I'm used to unix, where making a name visible > makes it available for both static and dynamic linking. That was the situation until GCC introduced the visibility stuff. > The idea that they might be different just seems weird > and unnecessary to me. > Well, I think that having mechanisms for the strict control of what symbols are exported from a shared library is a very good thing. > So I think that 'public' should probably make the name > both statically and dynamically linkable if reasonably > possible. > I assume that by 'statically linkable' you mean that symbols are visible across compilation units (i.e. different source files that sum-up to build a single shared library), right? Why do you want to support dynamic likability? Have you ever needed it? Do you know of people depending on this? Do you know of any use case of extension module interlinking? > I'm not sure about 'api'. I actually don't really like > having two different keywords for exporting names, it's > too confusing. But I haven't come up with a clear idea of > what I want to do about it. > I understand 'api' as a fundamentally different mechanisms for exporting symbols. This is the only one platform-agnostic, truly portable. It can work EVEN in the case of fully-static builds of Python+extmodules, in these platforms that do not support shared libraries at all. > Currently I'm thinking of dropping the 'api' keyword and > having a compiler option that would turn on api generation > for the whole module for anything declared in the pxd, > or maybe anything declared 'public', or both. Now that you said it, a similar approach could be this: 1) merge 'public' and 'api', perhaps by dropping 'api'. 2) Add a compiler directive/switch to decide the actual mechanism for exporting stuff: the non-static way for visibility across compilation units, the DL_EXPORT/D_IMPORT way, or PyObject/PyCapsule way, or both. -- Lisandro Dalcin --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
