Martin v. Löwis wrote: > One would have to study it in more detail. What > is the processing need of a Pyrex file?
Pretty simple -- just pass the .pyx file through the Pyrex compiler, then do whatever you would normally do to the resulting .c file to turn it into an extension module. A refinement would be to do this only if the .pyx or any .pyd it uses is newer than the last generated .c file. > I would > expect there is some activity on building, and > some activity on installing Nope, it installs just like any other extension once it's built. > Right, and the appropriate mechanism here is to > create a sub-command of build: Not sure exactly what you mean by a "sub-command". If you mean a subclass of the class that implements the "build" command, that's far too heavyweight. I want to deal just with the .pyx->.c transformation, and not have to worry that I might mess up something else that the build class does. Also, what happens if I want to use my extended build class together with someone else's extended build class? Do I have to merge them using multiple inheritance? Without knowing a *lot* about their internals, I'd be very nervous doing that lest they interact in unforeseen ways. > Right; changing that isn't easy (you could change > the installed Makefile, and have the change in > effect for all C extensions). That's actually what I ended up doing in my own Python installation. But it doesn't help anyone else. > However, I would argue > that it is really bad that Pyrex generates code > that compiles with warnings. It shouldn't do that. It *doesn't* generate any warnings using the normal, default C compiler settings -- only the extremely paranoid ones that the Python installation defaults to. It would take what I regard as an unreasonable amount of work on the part of Pyrex to change that. But that's a different rant. My point is that I failed to find a workaround, even by hacking. "Use the source, Luke" doesn't work if the source is so convoluted that ordinary mortals can't understand it. > Well, can you design a mechanism that would allow to > solve your problem with frameworks? If I were dealing with a Makefile, and there weren't a macro to override that would have the desired effect, I could replace the whole rule for linking C files with one of my own that did whatever I wanted. So if I were designing an architecture for this, I would base it on the way Make goes about things. That's something people are already familiar with, so they would have some idea how to approach extending and modifying it. Note that, again, the point isn't really about -F options, but that there are too few hooks exposed for modifying things. Maybe those hooks exist somewhere, but it seems you have to dig very deep and understand a lot more than you should have to in order to find and use them. > How would it operate on systems other than > the Mac? It wouldn't have to, because I'm only talking about tweaking someone's setup.py file so that it works on my system. A long-term solution to the framework problem would be to build knowledge of frameworks into the standard rules for compiling things on a Mac. If the rules were isolated from each other in a more Make-like way, this would be easier as well. > See, and I believe this isn't the case for distutils. Then we seem to have a difference of opinion on what the basic architecture should be like. I think it should be more like Make, and I don't see a way of getting there from here incrementally. -- Greg _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
