[asdf-devel] ASDF test-op question

[Tobias C. Rittweiler]

Robert Goldman writes:

> Juan Jose Garcia-Ripoll wrote:
>  
> > You are just imposing too much complexity. If I want to test package
> > Cl-UNICODE, I do nont want to test FLEXI-STREAMS or U-SOCKETS. Tests
> > should be atomic and not generate a tree of actions like ASDF does not
> > for everything.
>
> Please see earlier discussion about this topic.
>
> The point I made there is that systems may have COMPONENT subsystems
> such that you want to test the entire system together.
>
> Consider, e.g., a DB library with multiple backends, each described in a
> separate system.  In order to do the test-op on the DB library you want
> to do the test on all active backends.  Similarly, McCLIM has multiple
> graphics display backends, not all of which are loaded at a given time.
>    I work actively on three (or four, depending on how you count) large
> CL-based applications.  Each one of them is made up of multiple ASDF
> subsystems.

Yes, that is a valid use case. No one disputes that.

What if we start with the simple case of only carring one bit of
meta-information (successp), merging is nothing more than ORing together
the results.

This can be done in a way to satiesfy current needs without restricting
future improvement (which then can be based on actual experience in the
field.)

Notice that whatever we come up does not necessarily have to be part of
the exported API from the beginning but can be stated to be
experimental. We can, however, not achieve experience without trying.


> The example of CL-UNICODE is a strawman, because it is the case of
> testing a system and its libraries.  There is also the case of testing a
> system and its subsystems, which is the more interesting one.
>
> For that matter, though, if I am a CL-UNICODE /user/, I may very well
> want to test to see if it will work in its current installation, in
> which case I /do/ want to test FLEXI-STREAMS and U-SOCKETS, because I
> want to know whether my installation works.

Very true. It's related to a previous inquire of mine about the
recursiveness of :force. But it's a slightly different matter, and I'd
reach agreement on the issue above first.

  -T.