[Pyrex] New Distutils implementation for Pyrex.

[Billy G. Allie]

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.
>>>>> pyrex-create-listing: tells Pyrex to place error messages in a  
>>>>> listing (.lis) file.
>>>>>     
>>>>>           
>>>> I'm not sure this should be an extra option--it can be accomplished  
>>>> easier by piping to a file (or something else for that manner).
>>>>   
>>>>         
>>> Basically, the pyrex- options were added to allow the existing options
>>> for the Pyrex compiler to be  given in the setup.py file.  The pyrex
>>> compiler accepts an option to generate a listing file, so this option
>>> exists.
>>>       
>>>> Currently in Cython one can do cross-directory imports (like in  
>>>> python--essential for a project with 100's of extension modules), and  
>>>> this doesn't look like it respects that.
>>>>   
>>>>         
>>> The pyrex-include-dirs option only specifies additional directory to
>>> search for include files (i.e. the -I option to pyrexc).
>>>       
>> Hmmm, this sounds a lot like we don't really needed these options if
>> Cython/Pyrex evaluated the options already present in the Extensions objects.
>> I don't see much of an advantage in duplicating them.
>>     
>
> 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.
> This would also mean we could more easily provide the public files for the
> C-API as part of the install. They should get copied into the system include
> directory, next to Python.h, and could then be found by other Cython compiler
> runs.
>
> What do you think?
>
> Stefan
>   
In general, I don't see a problem with adding extension option to 
support Pyrex/Cython options (as defined in CompilationOptions class).  
I do not consider the Distutils implementation complete if you can't 
specify the options.  The include file option can be handled with the 
existing include_dirs option, but some of the others can't be handled 
with the existing options without changing the semantics of those 
options.   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.

As always, the above statement is my option.  Your's may vary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.copyleft.no/pipermail/pyrex/attachments/20070806/2d85e2e4/attachment.html