Erps, this bounced for some reason. Resending.. > I was noticing that this morning as I was playing with it. My questions are > mainly about what the process is supposed to look like.
Ok "big picture" time. .pxd's are redundant. All the information contained therein can be described in the .pym files directly. When a third party app compiles to extend PySoy they'd use an interface file, not a .pxd. We use .pxd's still only because it seems a faster way to get PySoy building in a stable manner again. Remember, beta-3 work is left to be done. What I would like to see in the end is the interface files for each extension built first in a specific directory under build, from distutils, before compile() is ever run. Then as compile runs it knows that cimport always describes an interface file either local or installed system-wide (ie, in site-packages next to the module itself). I've already resolved with robert, of the cython crew, that the convention for loading a C header will be cinclude, not cimport, so all those C library .pxd's are also obsolete once this code is written. Our entire include/ directory will, someday, be able to be deleted. > I noticed in setup.py (from pysoy) that the include directory is being set, > and that > from the errors the mill compiler is finding the .pyd files. But > then instead of > treating the .pyd files as an interface definition, it tries to compile them > as self-contained modules. Yea. Cython basically makes the sources=[] list redundant, since each Cython extension is built from exactly one file. This is the behaviour we need to change. > So, is the intent to somehow have the compiler treat declared but not defined > objects as forward declarations implicitly? Exactly. You'll see how the Cython.Compiler, via the mill.distutils, is milling all the .c sources to build/temp*/ right next to where the object files for the same are built by GCC, in the same way we'll need the C declarations written to a .h in the same directory and locally #include ""'d in each generated C file. > Also, would it be prudent to create a new distutils Command for mill so that > we aren't stepping on the existing build_ext? It might make it easier to > isolate the changes we want in the build process since we'll end up without a > lot of the implicit behavior in build_ext already (if there is any > interfering), and we can always go back to overriding build_ext if it turns > out that it's not a problem and still useful to have. There's no interfering. :-) Plus, as SWIG .i files are currently understood by distutils, I'd eventually like to see PyMill done the same way such that we don't need to implement our own distutils at all. When a .pym file is found in sources it'd just import mill and call the appropriate functions. _______________________________________________ PySoy-Dev mailing list [email protected] http://www.pysoy.org/mailman/listinfo/pysoy-dev
