On Mon, Oct 19, 2009 at 11:37 AM, Tobias C. Rittweiler tcr@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