On 2010-04-21, at 12:12 , Juan Jose Garcia-Ripoll wrote:
On Wed, Apr 21, 2010 at 11:50 AM, james anderson
<[email protected]> 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_______________________________________________
asdf-devel mailing list
[email protected]
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
