<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Stefan Behnel wrote:
<blockquote cite="mid46B5E8FF.3010108@behnel.de" type="cite">
<pre wrap="">
Stefan Behnel wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Billy G. Allie wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> Robert Bradshaw wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Aug 1, 2007, at 5:55 PM, Billy G. Allie wrote:
</pre>
<blockquote type="cite">
<pre wrap="">pyrex-cplus: tells Pyrex to use the C++ compiler to compile the
generated file.
</pre>
</blockquote>
<pre wrap="">Is this not handled by the "language" parameter in the
distutils.core.Extension used in setup.py
</pre>
</blockquote>
<pre wrap="">If Pyrex is not told to use the C++ compiler, it will generate a '.c'
file instead of a '.cpp' file.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
Then it should know about the "language" option rather than requiring its own one.
</pre>
</blockquote>
>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.<br>
<blockquote cite="mid46B5E8FF.3010108@behnel.de" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">pyrex-create-listing: tells Pyrex to place error messages in a
listing (.lis) file.
</pre>
</blockquote>
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">The pyrex-include-dirs option only specifies additional directory to
search for include files (i.e. the -I option to pyrexc).
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<blockquote cite="mid46B5E8FF.3010108@behnel.de" type="cite">
<pre wrap="">
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
</pre>
</blockquote>
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.<br>
<br>
As always, the above statement is my option. Your's may vary.<br>
</body>
</html>