[Pyrex] New Distutils implementation for Pyrex.

[Stefan Behnel]

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.

Which it can't in this case. It doesn't know Pyrex/Cython.


> Expanding it's semantics
> for Pyrex/Cython use doesn't make sense to me.

It makes sense to me, though. What you end up with is declaring an Extension
based on Cython sources where you pass an option "language='c++'" because you
want the extension to pass through C++ sources and the generated C++ sources
to be compiled with a C++ compiler. Note that it says "language" and not
"target_language" or "source_language".


>> So, what I'd propose here is to just let Cython obey the include_dirs option
>> of distutils and have it search its .pxd files there if they are not found in
>> the same directory as the source file. I don't mind if Cython or my C compiler
>> search a few directories more than necessary, as long as they find what I
>> need. And having a single place where include directories are defined makes it
>> easier to use and keeps us from defining new options.
>>   
> The search of directories in the include_dirs option already occurs if
> the pyrex_include_dires option is not given.  I included the
> pyrex_include_dirs option to support seperating the C/C++ only includes
> from the Pyrex/Cython includes (say for instance that a project has both
> C/C++ extensions and Pyrex/Cython extensions.  If you think that feature
> is not needed, it could easily be removed.

I think it's enough if you provide one list of include directories for
everything that needs includes along the tool chain (as long as they don't
interfere, but that's not a problem with Cython and GCC).


> In general, I don't see a problem with adding extension option to
> support Pyrex/Cython options (as defined in CompilationOptions class). 

But if you can avoid it, it makes life easier. Cython is only one of the tools
that patch around in distutils. Minimizing the impact helps compatibility.


> Also, in my option, you have to be able to supply the options
> on the command line and/or in the setup configuration file to be
> complete in your support of the extension type in distutils.

But that's up to the setup.py script, not to distutils themselves.

Stefan