On Sat, Sep 18, 2010 at 11:17 AM, Dag Sverre Seljebotn <[email protected]> wrote: > 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.
Our problems would be highly reduced if setuptools knew about Cython, simply by doing "have_cython_or_pyrex" instead of "have_pyrex", same for distutils. If one of the core developers can push for that simply acceptance, then wonderful. Another option is to make our package conflict with pyrex and install a Pyrex.py that in turns imports Cython. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
