On Thu, Nov 12, 2009 at 12:03 AM, David Cournapeau <courn...@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 5:42 AM, Tarek Ziadé <ziade.ta...@gmail.com> wrote:
>
>>
>> I am not sure he wants FOO, I think he wants all installation paths,
>> that gets built
>> by the install command with the provided "FOO" root prefix.
>>
>> that could be in pseudo code:
>>
>>>>> get_install_paths('FOO')
>>
>> And that's the API we want to add in sysconfig, roughly.
>
> That does not solve the problem about getting FOO in the first place
> when calling get_install_path.Why that ? where "FOO" comes from ? if it's an option you provide at build time like you said, earlier, you just pass it to the API to get the paths. FOO is not coming from nowhere... [..] > >> Do you mean, an Extension that would require several compilers ? >> >> I was thinking of a one-to-one relation between an Extension and a >> compiler type, >> even if there are are multiple source files (in different languages) >> for this extension. > > This cannot work - you need different tools at different stages. I > don't think any imperative method can work here. Note also that > extension alone is not enough to trigger the right tool: it should be > overridable on a per extension-basis (actually, it should be > overridable on a per source basis if needed). > > I think compiler class and the likes should simply be removed of the > picture here. You need tasks to transform a source into a target, and > tasks would use compiler configuration. There should not be any > objects/classes for compilers, it it not flexible enough. > Although > the details differ in significant ways, both waf and scons use strings > for command lines (waf "compile them" for performance reason), > consisting of different parts which can be altered at will. In scons, > the task to compile C code is something like > > $CC $CFLAGS $CPPDEFINES $CPPPATH -c $SOURCE $TARGET > > You need to be able to control those variable content in a very fine > grained manner: prepending and appending may lead to different > compiler behavior, for example. This is especially important when > linking, where the wrong order may be the different between a working > extension and a crashing extension. > > You cannot obtain this with classes and objects (especially when you > start talking about performance: thousand of source files for one > extension is not a crazy usercase). Sorry, I am getting confused here. This is getting all mixed up. What OOP has to do with performance in the first place ? OOP is useful to describe patterns and resuability, and that's what Distutils does. OOP is not a bottleneck here for speed. (everything is an object in Python anyways) Now we are saying that the compiler pattern in Distutils doesn't fit some requirement, fine, let's see what other design we can have. But that will be based on OOP with classes, and objects, and there ought to be an object that orchestrates the building of one given extension at the end. That might be the existing Extension class. This class is instanciated with a name for the extension, and a list of files. Here's a proposal to restrict the scope: let's drop the concept of "compiler class" and let's work only with the Extension class. This class is used by a distutils command to build a given extension. Let's say it is standalone, and it has a unique "build()" method. Could we take it from here and try to prototype this Extension class ? Tarek _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
