On Thu, Jun 11, 2009 at 10:24 AM, Stefan Behnel<[email protected]> wrote:
>
> Ondrej Certik wrote:
>> On Thu, Jun 11, 2009 at 1:59 AM, Stefan Behnel 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.
>
> Ok, I get it, so all that's missing here to make this work is put either
> the __init__.py files next to the binaries or the binaries next to the
> __init__.py files.
Yes, but putting binaries next to __init__.py files essentially means
building in the tree (then I can just build in the tree from the
beginning, which I do, but other people prefer not to pollute the
build tree), and putting __init__.py files next to binaries doesn't
work for me, because I then have the same module twice in my import
path (once in the source directory, once in the binary directory) and
it clashes -- at least I didn't make it work.
>
>
>> 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
>
> Yes (although it doesn't "mangle" them). Cython needs to know the fully
> qualified module names to correctly handle class cimports. Otherwise, the
> type would be known with one name in the module that implements it and with
> a different name in the module that cimports it. Greg would know this better.
>
> BTW, this has been discussed before (on the Pyrex list, I guess).
I found this:
http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/source_files.html
where it says:
"
If you don't do this //fully qualified module names//, you may find
that pickling doesn't work, among other problems. It also ensures that
the Pyrex compiler has the right idea about the layout of the module
namespace, which can be important when accessing extension types
defined in other modules.
"
so I guess it's not worthy to patch cython to do what I want. But I
still have a feeling that this is only an implementation detail in
cython, since Python itself can work this way, so I don't see why
Cython couldn't as well.
Ondrej
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
