wild-modules were an example extension and/or contrib from the asdf 1 days. There is a test for them in test/ but otherwise I don't believe anyone uses them. If you have the asdf git installed, you can use them with package-inferred-system.
I believe that package-inferred-system is a better way to achieve a similar effect, that allows for dependencies between sub-systems, unlike wild-modules. I suppose a wildcard option to load all files in a directory while using package-inferred-system dependencies would be a nice feature to add. But so far, I found it more practical to have an explicit file named "all.lisp" that includes all the files that matter. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Quality means doing it right when no one is looking. — Henry Ford Morality means doing the right thing when no one is looking. — Jan Krepelka On Fri, Jun 24, 2016 at 1:44 PM, Robert Goldman <rpgold...@sift.net> wrote: > On 6/24/16 Jun 24 -12:31 PM, rcn wrote: >> Hi all, >> >> Will wild-module support ever be fully and "officially" supported? >> >> Currently there's what appears to be a sample implementation as part of >> asdf/contrib but, if I recall correctly, asdf/contrib is bound to >> disappear eventually (actually, the documentation says this is an empty >> package). However, it's not clear how to use it, it's not documented and >> it's not clear if it will ever be a part of asdf or not. >> >> In my mind, this is an useful feature. Not for small systems (which, >> sadly, are the majority of Common Lisp open source projects), but for >> large systems where new files may be added to a directory to incorporate >> additional functionalities (a plug-in kind of thing). >> >> In these scenarios, wild-module definitions would ease development and >> system maintenance greatly. As far as I know, asdf is perfectly capable >> of implementing it and it looks to me like an implementation-agnostic >> feature, so I see no reason not to include as a core component. > > AFAICT, wild-modules are completely undocumented and, since I wasn't > involved in their development, I don't understand what they are for, or > what they are supposed to do. There are neither docstrings nor comments. > > I also note that the code in contrib is more than 3 years old, so likely > doesn't even work. > > So I am not in a position to answer your question (except by saying "WTF > is a wild module?"). > > In order to move towards integration, I would like to see some kind of > specification to describe the intended function of WILD-MODULE, and how > we intend to meet the specification. > > Then we could move forward with getting the code integrated, and some > appropriate documentation into the manual. A test suite would also be > required before we could "ship" WILD-MODULEs. > > Best, > r > > >
