On 2010-04-21, at 12:12 , Juan Jose Garcia-Ripoll wrote:

On Wed, Apr 21, 2010 at 11:50 AM, james anderson <james.anderson@setf.de> wrote:

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.

the build script performed a simple load-system. while the patches are from the first experiment, which was based on 1.5 as it is simpler, the later tests were based on 1.702. i quote, again, from the original message:

[ ... ] the logical
pathname based location maps were then re-implemented in 1.702 and
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. the following host definition, for example, produces a
centralized per-runtime translation tree for output files.

it used a standard project build script for cross-runtime tests.[1,2] as this thread is to discuss in principle, yet another diff would distract. if it would help to have a diff against 1.702, i can get one and post it.

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 do not understand "laying around". subsequent to the build, the source directory contained source files only and the ecl-.... shadow tree contained .o and .fas files. this is as i had thought it was supposed to have been.

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.

yes, as it was implemented that would be the case. the point of the experiment was not to demonstrate the best integration and api, but to investigate whether the mechanism satisfies the functional requirements.

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.

the implementation intended to leave logical pathnames alone. if the system is expressed in terms of lp-conformant components, there is no reason for asdf to translate anything. it is certainly possible that the patch would not work that way, but it should.