On Wed, Sep 16, 2015 at 11:46 AM, Robert Goldman rpgoldman@sift.net wrote:
On 9/15/15 Sep 15 -4:31 PM, Faré wrote:
However, whereas using LISP=ccl as the driver correctly invokes buildi.exe, using LISP=allegro as the driver leads to alisp.exe being called, which is not what I wanted. I haven't investigated why.
That was because defining LISP=allegro resulted in exporting ALLEGRO= which wasn't defined with LISP=ccl, and that ALLEGRO overrides the mechanism that in lisp-invocation calls buildi.exe instead of alisp.exe.
If you (Kevin, or any Allegro/Windows user) considers that it's a bug worth fixing rather than a feature, please propose an API as to how lisp-invocation should detect the correct way to invoke alisp.
Our test scripts have created an a morass of environment variables for invoking lisp that are very difficult to understand. The cascade from the makefile through the test scripts to the lisp-invocation library makes this particularly confusing.
Yes, there's a lot of confusion going on due to too many configuration variables. The situation is only made worse because many important implementations have no simple standard way of being invoked, and can't usually be trusted to have a reliable name found on the $PATH: lispworks doesn't even come with an console-only executable, allegro has this complex number of variants, ccl has an architecture-dependent name, etc. If I could rely on a same name and on being on $PATH, that'd be much easier. clisp and sbcl kind of have that on Linux, but clisp isn't actively maintained anymore.
I think it would be worth trying to overhaul this, but the first step is understanding what's going on in lisp-invocation. I'm not entirely sure if this library is required for correct ASDF functioning, or only for testing. I think many of the bundle operations, while they may not officially require lisp-invocation, *assume* it, because they assume a portable means of using the various bundles that are built with ASDF now.
ASDF requires no library whatsoever for proper functioning, or for installation. It's only the test and release script that requires libraries at all. In the master branch, you need a Unix installation or cygwin. In the minimakefile branch, you don't even need cygwin.
I regret the inclusion of the bundle operations as substantially complicating ASDF and its maintenance. OTOH, ASDF really didn't support the "hosted-on-C" flavors of CL without the bundle operations.
You're underestimating what the bundle operations brought to ASDF 3, even on "non-C-hosted" implementations. They do work and bring a lot: * {monolithic-,}compile-bundle-op allows delivery of a system {and its dependencies,} as a single fasl. That's invaluable. * {monolithic-,}concatenate-source-op, which was critical in allowing asdf itself to be split into individual source files, relies on some the bundle-operation infrastructure. * image-op and program-op couldn't have been fully portable without bundle-operations, and wouldn't have been attempted.
Sure, lib-op is currently broken on non-C-hosted implementations. I can fix that.
I would like to see them disabled and untested on conventional CL implementations: I don't think the burden on ASDF maintenance is justified by value to users.
I would like to see them working, and made to do great stuff: ideally, program-op would take the output of monolithic-lib-op (and/or all the individual lib-op's), link them into the implementation's runtime and produce a fully standalone executable. We could have that for ASDF 3.2.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "Wherever you go, there you are!" Dual: "Wherever you are, thence you go." Beats "I'll start exercising as soon as I'm into shape."