[asdf-devel] ASDF test-op question

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Mon Oct 19 10:09:24 UTC 2009


On Mon, Oct 19, 2009 at 11:37 AM, Tobias C. Rittweiler <tcr at freebits.de> wrote:
> Juan Jose Garcia-Ripoll writes:
>> Blocking this development just because there are 5 test suites and you
>> do not know how to combine them with ASDF is really absurd. ASDF's
>> specifications can not depend on what your company or other people's
>> companies are setting up for their workflow.
>
> Blocking is way too strong a word. After all, both of us want to
> piggy-back onto work of others. We can just hope to make our case clear
> to those who contribute code---or contribute ourselves.

I am really sorry if I was too rude in the wording. Subtleties are not
my strong point.

What I really meant is that just getting stalled in trying to match
everybodies needs by combining ASDF with 5 test modules, several build
systems, and the uses and abuses of tenths of Common Lisp developers
is not rational. One should break the ice by including a bare minimum.

Suppose one defines TEST-OP's perform method as returning (VALUES x y)
- x= NIL, signalling failure
- x= T, signalling success
- y= An optional sequence of objects representing test failures
Different test suites may create their own operation, RT:RT-TEST-OP,
for instance, which run all tests and return the appropriate output.
But at the very least the developer may define its own perform
operation with an EQL specialization which applies to its own system.

I would myself, but I have had problems with ASDF's internals in the
past and I still do not understand how it really works or the logic
behind the internal functions--should be pretty evident from my
continuous questions about how to best re-write our current code for
ECL/ASDF integration.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com




More information about the asdf-devel mailing list