[Pyrex] New Distutils implementation for Pyrex.
Billy G. Allie
bill.allie at defiant.mug.org
Fri Aug 3 06:04:08 CEST 2007
Stefan Behnel wrote:
> Billy G. Allie wrote:
>
>> I am re-implementing my PostgreSQL interface (pyPgSQL) using Pyrex to
>> implement an extension for the libpq C-API. When using the supplied
>> build_ext, I notices that I had to have the .pxd files in the same
>> directory as the source .pyx file. Also, the generated c source file
>> was placed in the same directory as the Pyrex source. I also could not
>> specify Pyrex options to create a listing file, etc. I wanted to have
>> the .pxd files in an separate include directory and I also did not want
>> to clean up the generated files from the Pyrex source directory. To
>> correct these (minor) annoyances, I've implesmentd a new version of
>> buld_ext.py and created a version of core.py and extension.py.
>>
>
> Hi,
>
> is this an independent implementation or is it based on the old one? If the
> latter, could you provide a patch against Cython and submit it at the Cython
> bug tracker? If it's new, could you still provide a single-file patch that
> includes the new files? We use Mercurial as version control system (meta data
> is in the source distribution), so an "hg export" would be greatly appreciated.
>
> https://bugs.launchpad.net/cython
>
> http://www.cython.org
>
It's independent. What I did was modified the Python 2.4.x distutils to
add the pyrex support, then created created diffs of the changes. I then
created the core.py, build_ext.py, and extension.py files to incorporate
the changes in a manner that did not require changes to the original
distutils files.
>> This implementation of Pyrex.Distutils will:
>>
>> 1. put the generated files (*.c, *.h, *.pxi) into the
>> [build_temp]/pyrex directory (unless the --inplace option is used).
>>
>
> This might touch the generation of the public C API in Cython. It generates a
> public .h file that should be part of the distribution. (Although Cython does
> not currently include it automatically either...)
>
I wonder if distutils can be made aware of that. I haven't used Cython
yet. When I do, I will look into it.
>> 2. add the following Pyrex specific command-line options:
>> * pyrex-include-dirs: a list of directories that Pyrex will
>> search for include files (the -I option of pyrexc)
>>
>
> Don't distutils support something like this already?
>
It has an include-dirs command line option that specifies the location
of any C headers to give the C compiler. My implementation will pass the
paths in the include-dirs option to Pyrex if the pyrex-include-dirs
options is not specified. By including pyrex-include-dirs you have the
option of putting all the Pyrex includes (.pxd files) in their own
directory, seperate from the C header files. (or the C and Pyrex header
files can be in a single directory, in which case you just specify the
include-dirs option).
>
>> * pyrex-create-listing: tells Pyrex to place error messages in
>> a listing (.lis) file.
>> I am also supplying a patch to Pyrex's Main.py that will place the
>> listing file in the same directory as the output file, instead of in the
>> same directory as the source file.
>>
>
> What is this error listing used for?
>
Any Pyrex (not C compiler) generated errors and warnings will go the the
listing file instead of to stderr when pyrex-create-listing is set to 1.
> I'll look through your code for now to see if it matches with what Cython
> currently does.
>
> Thanks for the contribution.
>
> Stefan
>
>
> _______________________________________________
> Pyrex mailing list
> Pyrex at lists.copyleft.no
> http://lists.copyleft.no/mailman/listinfo/pyrex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.copyleft.no/pipermail/pyrex/attachments/20070803/3d2c91b1/attachment.html
More information about the Pyrex
mailing list