[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