Proposed change to ccompiler classes
While hacking on a setup script for the win32all extensions, I encountered a problem with the distutils' ccompiler class(es). The compile() method determines which files have to be compiled, and constructs a dictionary 'build'. This contains as keys the object filename, the corresponding values are 2-tuples containing the source filename and the extension of the source filename. Later, the files are compiled using this loop: for obj, (src, ext) in build.items(): .... So, the files are compiled in a random order. For Windows, however, there may be the requirement that a certain build order is required, because the compilation of some files creates other files, which may be included by the following compilation steps. To give an example, there are '.mc' files which are first compiled by the so called messagecompiler. A '.h' file is also created, which is included by other source files. The essence is that a certain compile order is required. I can see two solutions: - Enhance the compiler classes with a method which will bring the files into the correct order, then make sure that they are actually compiled in this order. - Change the code so that the files are compiled in the order of the sequence passed to the compiler, and let the setup script writer take care that the order is correct. The latter is the easiest option, and this change would enable this - although it must be done in each compiler class: #for obj, (src, ext) in build.items(): for obj in objects: try: src, ext = build[obj] except KeyError: continue .... Any thoughts? Thomas
Thomas Heller wrote:
I can see two solutions: - Enhance the compiler classes with a method which will bring the files into the correct order, then make sure that they are actually compiled in this order.
- Change the code so that the files are compiled in the order of the sequence passed to the compiler, and let the setup script writer take care that the order is correct.
The latter is the easiest option, and this change would enable this - although it must be done in each compiler class:
#for obj, (src, ext) in build.items(): for obj in objects: try: src, ext = build[obj] except KeyError: continue ....
Any thoughts?
Yes, the second solution looks like the right thing to do. May I add another RFE here that somewhat relates to your proposal: Right now an 'Extension' is basically a flat list of files, to which some parameters are associated, specifying the build procedure. I'v had to work with code (all belonging to the same 'extension module'), where some files needed other compiler options than the rest. Would it be possible to allow 'Extensions' to be composed not only of files, but of 'sub extensions' ? Each such 'sub extension' would contain its own parameters (possibly inheriting default values from their parent), and the final link stage would just combine all the thusly generated .o files into one module. That seems completely doable, and even fully backward compatible. Of course, there, too, the order of execution may be important. Comments ? Regards, Stefan
On 6 Nov 2003, at 20:53, Thomas Heller wrote:
I can see two solutions: - Enhance the compiler classes with a method which will bring the files into the correct order, then make sure that they are actually compiled in this order.
- Change the code so that the files are compiled in the order of the sequence passed to the compiler, and let the setup script writer take care that the order is correct.
I would prefer a way to specify the dependency, similar to "make".
But distutils design is already tather top-heavy as it is, so
practicality
may dictate your second solution...
--
Jack Jansen
Jack Jansen
On 6 Nov 2003, at 20:53, Thomas Heller wrote:
I can see two solutions: - Enhance the compiler classes with a method which will bring the files into the correct order, then make sure that they are actually compiled in this order.
- Change the code so that the files are compiled in the order of the sequence passed to the compiler, and let the setup script writer take care that the order is correct.
I would prefer a way to specify the dependency, similar to "make". But distutils design is already tather top-heavy as it is, so practicality may dictate your second solution...
Well, I would *like* to view the second option as a bug fix, especially because it doesn't solve the original problem. You specify a sequence of files, and they should not be compiled in random order. Andrew, what do you think? Oh, I wanted to mention this: It's possible to work around a *lot* of problems or limitiations in distutils with command subclasses in the setup script. But it's a pain to change the behaviour of the compiler instance. Thomas
participants (4)
-
A.M. Kuchling -
Jack Jansen -
Stefan Seefeld -
Thomas Heller