Re: errors when re-compiling CLISP on Slackware

C Habs <[email protected]> Mon, 19 Feb 2018 19:22:43 +0000
Newsgroups gmane.lisp.clisp.general
Message-ID <CANe8y8ZP0UDiju7hxjzi=A6TS6KMCESOFJrOyn9iG5GJK9Bw5Q@mail.gmail.com>
On Monday, February 19, 2018, [email protected] <
[email protected]> wrote:

> Hi,
>
> [from Slackware's build:]
> > ./makemake \
> >   --with-dynamic-ffi  \
> [...]
> >   > Makefile
>
> To me this looks like the very old recipes. Nowadays, the user typically
> don't use
> makemake themselves, because configure creates the Makefile(s).
>
> > make config.lisp
> > make init
> > make allc
> > make $NUMJOBS lisp.run
> > make interpreted.mem
> > make halfcompiled.mem
> > make lispinit.mem
>
> The use of these many targets  on the part of Slackware was too much IMHO.
> The Makefile has always
> contained enough dependencies to build lispinit.mem after halfcompiled.mem
> etc.
> Maybe this explicit list helped produce logs in more logical order? Or
> more specific error messages?
>  (IMHO, only "make allc" once made sense as an extra early target).
> By introducing explicit targets, you introduce dependencies on their names
> into your build script.
>
> That stuff also seems to predate the "linking sets" (and their required
> complexity, read
>  additional build infrastructure, directory layout etc.).
>
> https://clisp.sourceforge.io/impnotes/modules.html#linkset
>
> If you look carefully into the build process, you'll see that multiple
> lisp.run and lispinit.mem
> are built (in the directories named base, full and others).
> Most of these deserve to be tested.
>
> One doesn't start lisp.run -M lispinit.mem -B ... etc. these days.
> Instead the docs mention clisp -K full ..., and the clisp wrapper selects
> one of the lisp.run in the various directories.
>
> >As far as I am aware, Slackware endeavour to release the programs just as
> the originators/authors intended.
> Then switch to the "./configure --cbc" option that Sam talked about (or at
> least --cb, then run tests separately).
>
> Regarding running tests, you may want to disagree with the amounf of tests
> that
> are performed by the clisp build process and add more of them. Recent
> postings
> and bugs have demonstrated that it's important to run the tests of the
> individual
>  modules as well (if present), not only standard CL compliance tests.
>
> Regards,
>         Jörg Höhle
>

Thank you Jorg.

I'm not sure if you have been able to read previous posts. The Slackware
build script is not mine, or a user's. It is part of the Slackware
packages. My apologies if you are already familiar: as I understand,
Slackware has a working CLISP program that was built , using what you see ,
by the ' maintainers' or 'owners'. Slackware does advise that because this
original build may have been done some time ago, that some programs may not
compile under later releases (even if the program still runs OK).

I was trying to rebuild to include the FastCGI module and encountered a
build failure which came from what seemed like tests. I have not made any
comment on whether these are appropriate or not...only that they seem part
of the error problem.

It does seem that to rebuild CLISP on Slackware, that the original build
approach will need to amended or tidied up. As I previously said, I'm not
very knowegeable with CLISP, so I was firstly trying to get some assistance
on *where exactly* in the CLISP build process the errors I posted were
coming from. Sam kindly asked me some questions which I answered. I am
still unclear though.

In the end, it may be better to refactor the clisp.SlackBuild  to take into
account your observations and Sam's. I will now go and ask on Slackware
forums how best to approach this (as a user not a maintainer). Thank you
both for your time.

If you feel you can offer any further advice specific to the Slackware's
clisp.SlackBuild build script (the configure and make parts )  to best
reflect the newer CLISP building approach, that would be great. In any
case, I have learned a bit to go forward with :-)

Best
Habs
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
clisp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-list