[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