On Thu, Jun 11, 2009 at 1:59 AM, Stefan Behnel<[email protected]> wrote:
>
> Ondrej Certik wrote:
>> we use cmake to build the project (C++ and cython) and cmake
>> allows to build the project out of the tree, e.g. it leaves the .cpp
>> and .py files in the source dir and creates a build dir, where it
>> stores all the .o and .so files.
>
> Uhm, so the real problem is that cmake fails to take the source directory
> structure into account when copying build artefacts over to the build
> directory?
I think cmake is doing it right, it only builds binary things in the
binary directory and leaves all the sources (be it python or C++) in
the source directory.
>
> How is that something to 'fix' in Cython?
Consider this cython statement:
from hermes2d._hermes2d cimport scalar, RealFunction, RefMap, WeakForm, \
int_grad_u_grad_v, int_v, malloc
This is essentially converted to a statement
py_module = PyImport_Import("hermes2d._hermes2d"); // Yes, I know
it's actually PyString in there and this is handled automatically by
__Pyx_ImportModule
Which is correct. Consider however this statement:
from _hermes2d cimport scalar, RealFunction, RefMap, WeakForm, \
int_grad_u_grad_v, int_v, malloc
which is converted to:
py_module = PyImport_Import("hermes2d._hermes2d");
which I think is not right, because Cython changed my import path (and
what is worse, it depends on the positions of the __init__.py files in
my directory). All I am asking is if there is a really good reason,
why Cython mangles the import paths, why it doesn't leave it to the
user. Here is the documentation for PyImport_Import:
http://docs.python.org/c-api/import.html#PyImport_ImportModule
it says that "Changed in version 2.6: always use absolute imports".
What does it mean? Does it mean that one should always pass absolute
imports in it? If that is the case, then that would be a reason why
Cython does it. But I created a simple hack to Cython, which leaves
the paths as they are read from the .pyx file and it works for me in
python2.6 and does exactly what I want. I still need to polish the
patch, as it fails in some other cases, but essentially it's just a
change in search_include_directories() and couple other places.
>
>
>> If the project is just C++, it is
>> then possible to use the build directory as is, e.g. you don't have to
>> install it and it still works (of course if you want, you can also
>> install it).
>
> For testing, I build my extensions using distutils' "build_ext -i", which
> creates the .so files inside the source tree (and leaves everything else
> out of sight).
Right, I use the same approach with cmake (e.g. building in the tree)
and that works fine.
Some of my colleagues however like to work out of the tree (which also
has its advantages), so I am investigating if that is possible with
Cython (it works just fine with C++, where it links all the libraries
in the correct places, and when it installs, it changes the library
paths in the binaries).
Ondrej
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
