Greg Ewing schrieb: > 1. Pyrex: The distutils extension for compiling Pyrex > modules (which was contributed, not written by me) > seems to work by abusing an existing mechanism for > dealing with swig files. That it was necessary to do > this rather than just adding something new is not a > good sign.
One would have to study it in more detail. What is the processing need of a Pyrex file? I would expect there is some activity on building, and some activity on installing (perhaps not so, as it may install as an extension). > Extension of distutils seems to revolve around the > idea of adding new commands. But I don't want to add > a command, I want to add a new kind of *object* (a > .pyx file) and specify how to transform it into > another kind of object (a .c file) which distutils > already knows how to deal with. Right, and the appropriate mechanism here is to create a sub-command of build: you are trying to explain how to *build* the .c file. > 2. Warnings: Distutils insists on compiling C code > with a ridiculously high warning level. Well, it really uses the settings that were determined when Python itself was compiled. It doesn't know at all what a compiler warning is and how to turn it on or off. > For code > generated by Pyrex this is counterproductive, so > I tried to figure out how I could get it to invoke > the C compiler with a different set of options. I > got hopelessly lost trying to follow the code and > gave up. Right; changing that isn't easy (you could change the installed Makefile, and have the change in effect for all C extensions). However, I would argue that it is really bad that Pyrex generates code that compiles with warnings. It shouldn't do that. > 3. Frameworks: On MacOSX it's often necessary to > link to something that's installed as a framework > instead of a library. Putting -F options in the > extra_link_args doesn't always work because > sometimes they need to be at the beginning. I > haven't found a way to make that happen. Can't comment here, since I never had this problem myself. > A well-designed extension mechanism would provide > fairly obvious ways of going about all these things. Well, can you design a mechanism that would allow to solve your problem with frameworks? How would it look like? How would it operate on systems other than the Mac? > Unless the basic structure is so far from what's > needed that it can't be reasonably fixed. See, and I believe this isn't the case for distutils. Regards, Martin _______________________________________________ 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
