Gustavo Sverzut Barbieri wrote: > On Fri, Sep 17, 2010 at 11:07 AM, Lisandro Dalcin <[email protected]> wrote: > >> On 17 September 2010 10:07, Gustavo Sverzut Barbieri >> <[email protected]> wrote: >> >>> changeset: 3753:62e52f105bc0 >>> tag: tip >>> user: Gustavo Sverzut Barbieri <[email protected]> >>> date: Fri Sep 17 09:42:57 2010 -0300 >>> files: Cython/Compiler/ModuleNode.py >>> description: >>> Force GCC>=4 to export module initialization function. >>> >>> With GCC's -fvisibility=hidden (both CFLAGS and LDFLAGS) it is >>> possible to have the compiler to produce binaries where all symbols >>> are hidden (local to the binary). To force a symbol to be visible one >>> must specify __attribute__ ((visibility("default"))). >>> >>> >> Why do you need to force -fvisibility=hidden ? In general, Cython >> emits 'static' storage specifier, unless 'public' or 'api' keywords >> are involved. >> > > I don't. But we recently moved from setuptools to autoconf due lots of > complaints of the former and I got tired and wasted 2 days to convert > all my bindings, and users had that in their CFLAGS as the whole > project compiles with it... except our bindings :-/ > > As for autoconf, later on I'll post the link to our examples... I even > created a cython.m4 to help finding cython, its version and already > cythonized files. What made us run away from setuptools is the deep > level of magic and dynamic patching: setuptools/distutils checked for > pyrex, thus I was faking cython as pyrex in sys.__modules__, but then > people asked for easy_install and that was importing setuptools before > we fake pyrex and then to unpatch all the classes was being a major > PITA. autoconf/automake is not much easier, as it requires lots of > code to get something done, but at least the rest of our developers > are used to it due the C libraries... :-/ > I can very much sympathize. People quickly discover that setuptools and distutils are not suitable for anything nontrivial and that the codebase is beyond repair. As an anecdote, at EuroScipy2010, every time someone mentioned they had problems building or distributing their Python software the room eccoed with "tell me about it". Building and distributing Python software seems to have become somewhat of a standing joke, at least within science and Python (with their need to mix Fortran, Cython etc. and run on various nonstandard cluster hardware).
The reason so much Cython documentation is written using distutils is, I think, because of the lack of an obvious alternative, not because anyone thinks distutils is such a great thing. IMO, if any solution comes to the mess of building Cython software it is not going to come from distutils or related tools (interesting reads on the subject are any rant David Cournapeau has on the subject on his blog or distutils-sig). BTW, David is or was the maintainer of the build system of NumPy and SciPy, which is about as complicated as it gets with Python packages. He's writing the Bento project ( http://github.com/cournape/Bento) for packaging Python software, which primary feature is not being distutils :-) Apparently, Bento is able to build projects with Cython in it now...I've been meaning to check it out but haven't got around to it. If Bento lives up to its promise and gets released in a stable version it'd be nice to establish usage of Bento as well as or instead of distutils in the Cython docs. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
