Wildcard modules support

[Ricardo]

The intended purpose of wild-module as defined in asdf-contrib is to 
specify a module composed of the set of files that match a glob pattern.

For example:

(defsystem "my-system"
   ...
   :components ((:file ...)
                ...
                (:wild-module "plugins"
                              :pathname "plugins/*.lisp")))

something like that, although the pathname specifier should rather be 
constructed in a platform-independent way.

The usefulness of this feature is that it avoids having to perform 
manual maintenance on the system definition file every time a "plugin" 
is added or removed from the system.
This is a pretty common thing on many projects and is easily handled by 
most (if not all) the system building tools I've come across in other 
platforms/languages.

However, I put aside half a day yesterday to try to hack a similar thing 
into asdf and I found the project code in a less than ideal state with 
regards to documentation, clarity and overall structure and methodology, 
which surprised me because asdf3 was introduced as a rewrite in the 
hopes of achieving better extensibility, consistency and 
configurability.
It's not clear at all where should someone plug these kind of features 
in or how to merge the behavior of a new specific component (not just a 
source-file subclass) into the whole control flow.

I'd like to contribute but I can't spend any more evenings on this when 
hardly anyone seems to need it. For my own purposes, the solution 
proposed in 
http://stackoverflow.com/questions/24171268/how-to-make-defsystem-use-everything 
works fairly well (and, actually, something as simple as this might as 
well be a built-in feature). Sorry.

Take care,
rcn

> I am, and I'm open to including this, but as I said before, not in its
> current state of non-documentation.
> 
> If we can get a description of its intended purpose, suitable for the
> manual and to check its implementation, I will review it for inclusion.
> 
> But ASDF has really grown, and I'm not in a position to incorporate any
> more bits that aren't clearly documented.  Rather the contrary: I'm
> interested in better understanding and better documenting.
> 
> Best,
> r