On Wed, Apr 21, 2010 at 11:50 AM, james anderson james.anderson@setf.dewrote:
further experiments demonstrated that - with changes to the scripts to account for functions which would be removed, all regression tests pass, and that with appropriate initialization, a multi-runtime build is supported for the normal abcl/acl/ccl/clisp/cmucl/ecl/lw/sbcl complement.
that is, the multi-runtime build included ecl. for which the expression of the functional requirements was the conditionalization in the output-files method. if that is the extent of the requirement, then ecl is taken into account.
I presume those tests only use the _default_ build system, not ECL's extensions. Your patches were produced against 1.5 and there the OUTPUT-FILES would only return one file, even for ECL.
However, once we integrated ECL's extensions, these produce two object files, and I fail to see from your patch how the output files are handled -- from what I can see, since the OUTPUT-FILES method does not have an :AROUND, the output of ECL's extensions is not translated: they just take the source file produce a compile-file pathname and that's it. In other words: it is going to work, but it is going to have files laying around, both translated and not.
I suppose in your model developers are expected to integrate an explicit call to component-translate-pathname in every method they define for output-files.
no, in that system instantiation protocol includes a step which
(effectively) walks the model to compute a location for each component.
Indeed, I find this an interesting approach, independently of what method is used for translation, but I see a problem if a user decides to temporarily deactivate translations or change the destination of a system. Right now it amounts to changing the translation table. With your model it involves re-reading and rebuilding the system and components.
Juanjo