[Pyrex] New Distutils implementation for Pyrex.

[Billy G. Allie]

Phillip J. Eby wrote:
> At 01:50 AM 8/6/2007 -0400, Billy G. Allie wrote:
>> Phillip J. Eby wrote:
>>> At 09:44 PM 8/5/2007 -0400, Billy G. Allie wrote:
>>>> If you want to give new options to extension you need to subclass
>>>> entension.py.
>>> And then just use those classes in your setup.py. You don't need to 
>>> patch setuptools for that.
>>>> If you want to have those new options available as command
>>>> line options (to setup.py), you need to wrap core.py (it can't be
>>>> sub-classed).
>>> Why do you need options to setup.py instead of just options to the 
>>> build_ext command?
>> You don't. They are build_ext options, but the command line is parsed 
>> by setup.py and unrecognized options will cause errors before 
>> build_ext is executed. The setup configuration file is also parsed by 
>> setup.py with unrecognized options causing errors.
> Not if you use setup(..., 
> cmdclass=dict(build_ext=my_build_ext_subclass), ...) it won't, because 
> it will ask your subclass for its supported options to do both the 
> command line parsing and the config file parsing.
>>>> My new Distutils for Pyrex does both. In order for
>>>> setuptools to compile pyrex extension (.pyx), it needs to use
>>>> Pyrex.Distutils.core instead of distutils.core. If you don't, just
>>>> loading build_ext will fail because of undefined extension variables.
>>> Per the above, none of this should be necessary.
>> Unfortunately, if you want to be able to specify extension options 
>> that can also be command line and configuration file options, you do.
>>
>> If I am mistaken about this, please let me know and give me an 
>> example of extension options that will also be command line and 
>> configuration file options.
> Unless I misunderstand what you mean by "extension options", then you 
> are indeed mistaken. Your build_ext subclass simply defines what 
> additional options it wants. For example, see setuptools' "install" 
> subclass, which adds an option called 
> --single-version-externally-managed. It is parsed by the distutils on 
> both the command line and in configuration files.
>
> (Of course, such options would be specified as "setup.py build_ext 
> --my-new-options-here", not "setup.py --my-new-options".)
>
In developing the original version of my distutils for Pyrex, I first 
made changes to the Python 2.4 distutils to enable Pyrex support. I then 
created core.py, extension.py and build_ext.py to implement those 
changes outside of the Python 2.4 distutils. That proved to be over kill 
(and not necessary). I've reworked my code to that only extension.py and 
build_ext.py are needed. Also, if you don't want to use the 
pyrex_include_dirs, pyrex_create_listing, and pyrex_cplus options as 
extension argument (they can still be used in setup.cfg and as build_ext 
command line options), then you don't even need etension.py. This 
build_ext.py is a drop-in replacement for the original build_ext.py. No 
changes to existing setup.py files are needed.

I am attaching the new extension.py and build.py files for Pyrex.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_ext.py
Type: text/x-python
Size: 6215 bytes
Desc: not available
Url : http://lists.copyleft.no/pipermail/pyrex/attachments/20070810/a6cb9ab9/attachment.py 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: extension.py
Type: text/x-python
Size: 2386 bytes
Desc: not available
Url : http://lists.copyleft.no/pipermail/pyrex/attachments/20070810/a6cb9ab9/attachment-0001.py 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: __init__.py
Type: text/x-python
Size: 393 bytes
Desc: not available
Url : http://lists.copyleft.no/pipermail/pyrex/attachments/20070810/a6cb9ab9/attachment-0002.py