ASDF 3.1.5 test suite issues on ACL (8.2 and 10.0 GM)

[Faré]

On Wed, Sep 16, 2015 at 11:46 AM, Robert Goldman <rpgoldman at 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."