<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=US-ASCII" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Robert Bradshaw wrote:
<blockquote
 cite="mid6859C27D-FA05-492A-9912-01486A4E170B@math.washington.edu"
 type="cite"><br>
On Aug 5, 2007, at 10:41 PM, Billy G. Allie wrote:
  <br>
  <br>
  <blockquote type="cite">Stefan Behnel wrote:
    <br>
    <blockquote type="cite">Stefan Behnel wrote:
      <br>
      <blockquote type="cite">Billy G. Allie wrote:
        <br>
        <blockquote type="cite">Robert Bradshaw wrote:
          <br>
          <blockquote type="cite">On Aug 1, 2007, at 5:55 PM, Billy G.
Allie wrote:
            <br>
            <blockquote type="cite">pyrex-cplus: tells Pyrex to use the
C++ compiler to compile the generated file.
              <br>
            </blockquote>
Is this not handled by the "language" parameter in the
distutils.core.Extension used in setup.py
            <br>
          </blockquote>
If Pyrex is not told to use the C++ compiler, it will generate a '.c'
file instead of a '.cpp' file.
          <br>
        </blockquote>
      </blockquote>
Then it should know about the "language" option rather than requiring
its own one.
      <br>
    </blockquote>
&gt;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.&nbsp; Expanding it's semantics
for Pyrex/Cython use doesn't make sense to me.&nbsp; 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.
    <br>
  </blockquote>
  <br>
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?
  <br>
  <br>
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.
  <br>
  <br>
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.
  <br>
  <br>
- Robert
  <br>
  <br>
</blockquote>
>From the (Python 2.4) source for extension.py:<br>
<blockquote><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; language : string<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extension language (i.e. "c", "c++", "objc"). Will be detected<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from the source extensions if not provided.<br>
  </tt></blockquote>
To me, this means that the language option is used to tell setup what
language to use to compile the extension, <i><b>not</b></i> to tell
Pyrex/Cython what output file to generate.&nbsp; The current Pyrex/Cython
distutils module ignores the language option.&nbsp; 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.&nbsp; So, if you want pyrex/cython to generate
C++ files instead of C files, you need to tell Pyrex/Cython to do so.&nbsp;
If you were running pyrexc you could do this with the --cplus option on
the command line.&nbsp; 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.<br>
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.<br>
</body>
</html>