[Pyrex] Cython development

Stefan Behnel stefan_ml at behnel.de
Fri Mar 14 19:48:39 CET 2008


Hi,

Arc Riley wrote:
> Up until the last release we were distributing pre-processed .c files.
> 
> We've received at least a dozen complaints (which means a t least a few
> dozen more) about this, that the .c source in our tarballs are unparseable
> by any sane human

Then put a clear warning into the docs/FAQ: "the C files are generated, please
ignore them when reading the source".


> that we haven't actually complied with the GPL's
> requirements in the "source" release since the .c sources are not what is
> intended to be modified

Distributing both the .c files *and* the Pyrex source would help here.


> and of course Windows users needing a separate
> source zip since we have OS-specific building going on the Pyrex level.

Interesting. lxml supports various different versions of libxml2/libxslt, each
with their own bugs and quirks etc. I guess that's comparable to platform
specific code. However, we can distribute our generated .c files together with
the normal sources, as all version specific stuff is handled in a separate
header file. There, we #define a couple of names that we declare as ints in a
.pxd file. Our Cython code is then based on those names, for example:

    cimport config # this defines the names from the header file
    ...
    if config.HAS_WHATEVER:
        dostuff()
    else:
        dootherstuff()

The header would be something like

    #ifdef STUFF
        #define HAS_WHATEVER 1
    #else
        #define HAS_WHATEVER 0
    #endif

And the .pxd goes:

    cdef extern from "config.h":
         cdef int HAS_WHATEVER

The C compiler then takes whatever branch is selected by the #defines in the
header. That way, we avoid any platform specific differences in the generated
C code.

Obviously, you may or may not be able to do something similar.

Stefan



More information about the Pyrex mailing list