On Thu, May 1, 2008 at 4:55 AM, Arc Riley <[EMAIL PROTECTED]> wrote: > 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.
I wonder if bypassing all of Cython except the parts we need for beta-3/4 is a possibility. Then, when we have it working well enough, work on bringing it back into Cython. > 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). > So basically it would generate the headers in a packagable and well-defined place, and then create the C code implementation files that include their own generated headers, and also any that were explicitly "cinclude"-ed? 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 think I see a quick and dirty way or two to at least get the code compiling. It won't necessarily be Cythonic, but maybe at least Milleresque anyway. And it might give more ideas to talk and/or argue about. 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. > Ah, got it (in theory). > 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. > Maybe breaking this down into smaller tasks will help, at least conceptually: 1. Mill single files with the right header generation. 2. Compile all the way to a loadable Python module. 3. Repeat for a single package. 4. Repeat for multiple packages. 5. Mill some soy. 6. ??? 7. Profit. -- Evan Cofsky, Horn Player [EMAIL PROTECTED] Check out my horn playing: http://tinyurl.com/47bvxr
_______________________________________________ PySoy-Dev mailing list [email protected] http://www.pysoy.org/mailman/listinfo/pysoy-dev
