<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br><div><div>On 2010-04-21, at 12:12 , Juan Jose Garcia-Ripoll wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Wed, Apr 21, 2010 at 11:50 AM, james anderson <span dir="ltr"><<a href="mailto:james.anderson@setf.de">james.anderson@setf.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div style="word-wrap: break-word;"><div class="im"><div><blockquote type="cite"><div style="margin: 0px;">further experiments demonstrated that - with changes to the scripts </div><div style="margin: 0px;">to account for functions which would be removed, all regression tests </div> <div style="margin: 0px;">pass, and that with appropriate initialization, a multi-runtime build </div><div style="margin: 0px;">is supported for the normal abcl/acl/ccl/clisp/cmucl/ecl/lw/sbcl </div><div style="margin: 0px;"> complement. </div></blockquote></div></div><div>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.</div> </div></blockquote><div><br>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.<br></div></div></blockquote><div><br></div><div>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:</div></div><div><br></div><div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">[ ... ] the logical </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">pathname based location maps were then re-implemented in 1.702 and </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">further experiments demonstrated that - with changes to the scripts </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">to account for functions which would be removed, all regression tests </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">pass, and that with appropriate initialization, a multi-runtime build </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">is supported for the normal abcl/acl/ccl/clisp/cmucl/ecl/lw/sbcl </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">complement. the following host definition, for example, produces a </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">centralized per-runtime translation tree for output files.</div></blockquote><br></div><div>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.</div><div><br></div><div><blockquote type="cite"><div class="gmail_quote"><div> <br>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.<br></div></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div class="gmail_quote"><div> <br>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.<br></div></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div style="word-wrap: break-word;">no, in that system instantiation protocol includes a step which (effectively) walks the model to compute a location for each component. <br></div> </blockquote></div><br>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.</blockquote><div><br></div>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.</div><div><br></div><div><blockquote type="cite"> Right now it amounts to changing the translation table. With your model it involves re-reading and rebuilding the system and components.</blockquote><br></div><div>it should be sufficient to redefine the logical host(s).</div><div><br></div><div>---</div><div>[1] : <a href="http://174.129.66.148:8000/metadata/net/common-lisp/alexandria/build-system.sh">http://174.129.66.148:8000/metadata/net/common-lisp/alexandria/build-system.sh</a></div><div>[2] : <a href="http://174.129.66.148:8000/metadata/lib/html/build-20100421T111506Z00.html">http://174.129.66.148:8000/metadata/lib/html/build-20100421T111506Z00.html</a></div></body></html>