[Pyrex] New Distutils implementation for Pyrex.

Billy G. Allie bill.allie at defiant.mug.org
Fri Aug 10 06:33:58 CEST 2007


Robert Bradshaw wrote:
>
> On Aug 5, 2007, at 10:41 PM, Billy G. Allie wrote:
>
>> Stefan Behnel wrote:
>>> Stefan Behnel wrote:
>>>> Billy G. Allie wrote:
>>>>> Robert Bradshaw wrote:
>>>>>> On Aug 1, 2007, at 5:55 PM, Billy G. Allie wrote:
>>>>>>> pyrex-cplus: tells Pyrex to use the C++ compiler to compile the 
>>>>>>> generated file.
>>>>>> Is this not handled by the "language" parameter in the 
>>>>>> distutils.core.Extension used in setup.py
>>>>> If Pyrex is not told to use the C++ compiler, it will generate a 
>>>>> '.c' file instead of a '.cpp' file.
>>> Then it should know about the "language" option rather than 
>>> requiring its own one.
>> >From my reading of the 'language' option, it's supposed to tell 
>> setup.py what language the extension is written in when setup.py 
>> can't determine the language from the file extent. Expanding it's 
>> semantics for Pyrex/Cython use doesn't make sense to me. I would also 
>> point out that the SWIG support also has a flag to tell swig to 
>> generate C++ as opposed to C and does not use the 'language' option 
>> for this.
>
> As I understand it, Pyrex/Cython uses the language option to generate 
> either a .c or .cpp file, which is then (correctly) handled by 
> setup.py. Could you please clarify what is not supported/possible in 
> the current implementation that you are trying to enable/fix?
>
> Though I would probably never use it, I am not opposed to having extra 
> include paths that can be specified for pxd, pxi, etc. files.
>
> I would rather to the least patching of distutils possible, it seems 
> most if not all of this stuff can be specified in setup.py.
>
> - Robert
>
 From the (Python 2.4) source for extension.py:

    language : string
    extension language (i.e. "c", "c++", "objc"). Will be detected
    from the source extensions if not provided.

To me, this means that the language option is used to tell setup what 
language to use to compile the extension, /*not*/ to tell Pyrex/Cython 
what output file to generate. The current Pyrex/Cython distutils module 
ignores the language option. Also the swig support does not use the 
language option, it has it's own option to specify the generation of C 
or C++ files. So, if you want pyrex/cython to generate C++ files instead 
of C files, you need to tell Pyrex/Cython to do so. If you were running 
pyrexc you could do this with the --cplus option on the command line. 
Withing the distutils framework, you would need to defiant an option 
(i.e. pyrex-cplus) to let pyrex/cython know to generate a C++ file.
Using the language extension option to do this would be changing the 
original semantics of that option, which IMHO is not the right thing to do.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.copyleft.no/pipermail/pyrex/attachments/20070810/0a6090c3/attachment-0001.html 


More information about the Pyrex mailing list