[asdf-devel] ASDF 2.0 requirements : simplify the output locations mechanism

[james anderson]

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 at 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.

> Right now it amounts to changing the translation table. With your  
> model it involves re-reading and rebuilding the system and components.

it should be sufficient to redefine the logical host(s).

---
[1] : http://174.129.66.148:8000/metadata/net/common-lisp/alexandria/ 
build-system.sh
[2] : http://174.129.66.148:8000/metadata/lib/html/ 
build-20100421T111506Z00.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100421/27717fe8/attachment.html>