But loading all the required files from an "all.lisp" file makes asdf unaware of the existence of those files, doesn't it? I can use that as a workaround but it has several disadvantages: The relationships between those files and the rest of the system will be lost, and any changes with regards to compilation/loading configuration (bundling, loading from pre-compiled files) will have to be done manually in all.lisp, hidden from the project .asd file.
Given that a workaround is necessary for this, using a reader macro in the system definition to unfold a list of :file components from a glob pattern seems like a better solution, but it's a shame that such a basic feature isn't supported out of the box.
In my opinion, if you really want to push asdf as the standard system definition for Common Lisp, these kind of things (what the users need, after all) should be given more attention. It's unusual for a programming ecosytem to have a powerful system definition tool and still having to rely on Makefiles and roll-your-own hacks for some things.
Don't get me wrong, I think asdf is a great tool and I thank you all for the effort you put on it.
Kind regards, rcn
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.
On Sat, Jun 25, 2016 at 9:34 AM, rcn rcn@lateralt.net wrote:
But loading all the required files from an "all.lisp" file makes asdf unaware of the existence of those files, doesn't it?
I'm not sure what you mean. ASDF can follow the dependencies of all.lisp and become aware of whichever files are used.
I can use that as a workaround but it has several disadvantages: The relationships between those files and the rest of the system will be lost, and any changes with regards to compilation/loading configuration (bundling, loading from pre-compiled files) will have to be done manually in all.lisp, hidden from the project .asd file.
I'm not at all sure what you mean.
I use all.lisp a lot in lisp-interface-library, and I am not aware of missing out on any feature.
Given that a workaround is necessary for this, using a reader macro in the system definition to unfold a list of :file components from a glob pattern seems like a better solution, but it's a shame that such a basic feature isn't supported out of the box.
You can use :defsystem-depends-on to load asdf extensions then use them.
In my opinion, if you really want to push asdf as the standard system definition for Common Lisp, these kind of things (what the users need, after all) should be given more attention. It's unusual for a programming ecosytem to have a powerful system definition tool and still having to rely on Makefiles and roll-your-own hacks for some things.
Don't get me wrong, I think asdf is a great tool and I thank you all for the effort you put on it.
I don't actively maintain asdf anymore, but Robert does, and I'm sure he is accepting patches.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org No one can make you feel inferior without your consent — Eleanor Roosevelt But you're only fooling yourself if you can't recognize your superiors — #f
On 6/25/16 Jun 25 -5:45 PM, Faré wrote:
I don't actively maintain asdf anymore, but Robert does, and I'm sure he is accepting patches.
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