[Pyrex] New Distutils implementation for Pyrex.

[Stefan Behnel]

Hi,

Billy G. Allie wrote:
>>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.

Even if it changes the semantics, I don't see why you need a different option.
There are currently only three cases:

1) you want to generate C code. Then you can either specify - language="c" -
or not use the option at all. Both work nicely with current Pyrex/Cython.

2) you want to generate c++ code and use additional C++ source files in the
same extension. Then you will either specify the language option to "c++"
(which Pyrex/Cython could evaluate) or let distutils recognise the file
extension automatically (which Pyrex/Cython could do alike). An additional
option for Pyrex/Cython is overhead IMHO and can lead to conflicts if both
happen to be set inconsistently.

3) you want to generate c++ code and do not use any additional C++ source
files in the extension. Then you have to pass some option to Pyrex/Cython to
make it generate C++ code. I don't see why you can't just stick to the
language option in this case, which already works nicely for the two cases above.

It's not only a matter of extending (rather than changing) semantics. It's
also a matter of simplicity. Why add an option that only introduces overhead
and potential conflicts with existing options?

Stefan