[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