I know why we have done this, but I deeply regret it.
ASDF claims to be able to do things like build C code to be linked into lisp systems.
It cannot do this without something like ASDF:RUN-SHELL-COMMAND.
I understand that XCVB-DRIVER:RUN-PROGRAM is proposed as an alternative, but this adds a dependency chain to ASDF in a way that I feel to be unfortunate.
Even though it will make ASDF bigger, I would like to see ASDF:RUN-SHELL-COMMAND (or RUN-PROGRAM) get undeprecated, possibly by having ASDF eat its own copy of XCVB-DRIVER:RUN-PROGRAM.
I understand the history of CL enough to know why RUN-PROGRAM was not in the original ANSI spec, but now that CL has moved to general-purpose computers, I think it's something that we need to provide integrally. And putting it into ASDF is as close as we can come to doing that.
[As an aside, I can see the tidiness advantage of shattering the full set of functions into a large set of smaller libraries. However, this makes configuring a reasonably sized CL software development project into a chore of herding a very large set of small libraries. This is not something that our community has the person-hour resources for -- many of our libraries fall into an un-maintained state. Philosophically, I have a bit of a beef with this position, too --- this is, after all Common Lisp, and not Scheme.]
Cheers, r
Dear Robert,
regarding ASDF and libraries, I think I have a solution that will satisfy everyone.
I will adopt the plan once proposed by James Anderson, back when ASDF was one third the size that it is now: split ASDF into many parts, and programmatically reconstitute it into a single source file for bootstrapping purposes.
Now that ASDF is bigger, this makes even more sense than it did then. Now that ASDF includes ASDF-BUNDLE, it is easier to do that it used to, in a way that is well-managed by ASDF itself.
Therefore, I will split ASDF into several libraries. These libraries will each get their own .asd file, and can each be upgraded separately.
I will add a concatenate-all-source-op that recursively descends into all system dependencies, concatenates all sources, and creates the output file asdf.lisp, also including defsystem fallback stubs to make upgrade easier, just like the current asdf defsystem fallback stub.
This way, ASDF can enjoy the advantages of both a "large set of small libraries" and a "single-file bootstrap solution". Also, adding new extensions to ASDF will be easier.
XCVB's RUN-PROGRAM/ will be in one of these libraries. RUN-SHELL-COMMAND will be made a thin wrapper around it, and moved to a separate backward-compatibility file, where all functions are marked "obsolete, do not use", and given an expiration date (say, two or three years afterwards).
However, making sure everything in Quicklisp compiles properly and releasing 2.27 takes precedence over this refactoring.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The last ten percent of any reform is the most difficult to achieve. Moreover, it is often harmful. — John McCarthy
On Sun, Jan 6, 2013 at 11:45 AM, Robert Goldman rpgoldman@sift.info wrote:
I know why we have done this, but I deeply regret it.
ASDF claims to be able to do things like build C code to be linked into lisp systems.
It cannot do this without something like ASDF:RUN-SHELL-COMMAND.
I understand that XCVB-DRIVER:RUN-PROGRAM is proposed as an alternative, but this adds a dependency chain to ASDF in a way that I feel to be unfortunate.
Even though it will make ASDF bigger, I would like to see ASDF:RUN-SHELL-COMMAND (or RUN-PROGRAM) get undeprecated, possibly by having ASDF eat its own copy of XCVB-DRIVER:RUN-PROGRAM.
I understand the history of CL enough to know why RUN-PROGRAM was not in the original ANSI spec, but now that CL has moved to general-purpose computers, I think it's something that we need to provide integrally. And putting it into ASDF is as close as we can come to doing that.
[As an aside, I can see the tidiness advantage of shattering the full set of functions into a large set of smaller libraries. However, this makes configuring a reasonably sized CL software development project into a chore of herding a very large set of small libraries. This is not something that our community has the person-hour resources for -- many of our libraries fall into an un-maintained state. Philosophically, I have a bit of a beef with this position, too --- this is, after all Common Lisp, and not Scheme.]
Cheers, r
On Sun, 6 Jan 2013, Faré wrote:
I will add a concatenate-all-source-op that recursively descends into all system dependencies, concatenates all sources, and creates the output file asdf.lisp, also including defsystem fallback stubs to make upgrade easier, just like the current asdf defsystem fallback stub.
This way, ASDF can enjoy the advantages of both a "large set of small libraries" and a "single-file bootstrap solution". Also, adding new extensions to ASDF will be easier.
That sounds like it could be a very useful feature in general. For example, it would allow any program to be distributed with its all dependencies in a single source file.
Thanks, Daniel
On Tue, Jan 8, 2013 at 11:09 PM, Daniel Herring dherring@tentpost.com wrote:
On Sun, 6 Jan 2013, Faré wrote:
I will add a concatenate-all-source-op that recursively descends into all system dependencies, concatenates all sources, and creates the output file asdf.lisp, also including defsystem fallback stubs to make upgrade easier, just like the current asdf defsystem fallback stub.
This way, ASDF can enjoy the advantages of both a "large set of small libraries" and a "single-file bootstrap solution". Also, adding new extensions to ASDF will be easier.
It's done in branch exploded, which also creates one package per file, in the style of faslpath and/or quick-build.
I can't merge it to master until I write a variant of defpackage that will make the thing survive hot upgrade, but it's already a major cleanup. For the first time ever, ASDF sources are well-organized and mostly readable — and they are much more correct/robust, too.
That sounds like it could be a very useful feature in general. For example, it would allow any program to be distributed with its all dependencies in a single source file.
Yes, with limitations: 1- you mustn't rely on load-time effects of previous files during the compile-time of your file, unless they've been explicitly wrapped in an eval-when. 2- all your files must have the same encoding. 3- if you have an around-compile hook, it must apply to all files, and be already defined in some specially loaded prelude.
Also, I don't currently register fake/fallback systems for transcluded dependencies.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you don't like yourself, you *can't* like other people. — Robert Heinlein, "Time Enough For Love"
-
Daniel Herring -
Faré -
Robert Goldman