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-everyt... 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
"Ricardo" == Ricardo rcn@lateralt.net writes:
Ricardo> The intended purpose of wild-module as defined in asdf-contrib is to Ricardo> specify a module composed of the set of files that match a glob Ricardo> pattern.
Ricardo> For example:
Ricardo> (defsystem "my-system" Ricardo> ... Ricardo> :components ((:file ...) Ricardo> ... Ricardo> (:wild-module "plugins" Ricardo> :pathname "plugins/*.lisp")))
Ricardo> something like that, although the pathname specifier should rather be Ricardo> constructed in a platform-independent way.
While this probably works for something like plugins since they're very likely independent, doesn't this fail if there are dependencies between them?
For some projects I've done, I just did a simple emacs macro to get a directory list and wrap appropriate (:file ...) around each of them. That's easy. The hard part is getting all the dependencies right so that if you modify one file, asdf knows what files need to be loaded first and also knows what files depend on this file.
-- Ray
On 6/27/16 Jun 27 -10:00 AM, Ricardo wrote:
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.
I guess I don't see what you mean by "plugin." If a plugin is an essential part of the system, then I don't see it as a problem that you have to change the system definition file every time you add one.
I realize that make allows you to say "load all the C files," but those (as Raymond points out in a later email in this thread) are essentially independent, since the compiler translates them *and then exits* which is not the way the Lisp environment works. The lisp environment gives you a much richer context for compilation, for better or worse.
On the other hand, if the plugins are plugins like in a browser, then they should be loaded by the *user*, not the *developer*, and applying Faré's principle, the *user*, not the *developer* should choose where they go.
I'm not surprised that you found it hard to implement wild modules, since it would involve creating new components on the fly, based on a glob pattern match. I'd also point out that CL doesn't offer glob matching -- you wouldn't be able to count on :pathname "plugin-*.lisp" working reliably. Indeed, the "everything" solution that you point to on stack exchange will not work in general, since "e*.lisp" doesn't work in general.
If we overcame this problem (which would require combining regular-expressions with DIRECTORY), there are more: What class should the new components be? How do we handle updating an already-loaded system containing wild-modules? Do we expect that a second call to asdf:load-system will deal with additions and removals from the plugins directory? Note that this would require an extension to the way ASDF works -- and that the everything solution would fail here also, since there would be no way for ASDF to notice that it needs to re-evaluate the :COMPONENTS specs in the "euler" system.
As I said earlier, I'm not convinced that we have a clear specification of what wild-modules should do, and until I get such a specification, I'm not in favor of putting them in.
Indeed, unless I hear some howls of protest, I will remove wild-modules from contrib/ -- it's an "attractive nuisance" for programmers.
-
Raymond Toy -
Ricardo -
Robert Goldman