[PATCH] install aldor files to target/

[Qian Yun]

This patch install aldor files to target/
directory when running "make".

Currently, "make" does not install aldor files
to target/, and "make install" will install to
the system location instead of target/.

This patch will make the aldor part consist with
the rest of the system, and you can test the interface
locally, and it makes packaging easier
(I'm working on a CI test that tests aldor interface.)

- Best,
- Qian

[Waldek Hebisch]

That looks good to me, but I would like to know what Ralf thinks.

--
Waldek Hebisch

[Ralf Hemmecke]

I think about this "target" directory later.
We must first fix a regression.

In 07c1768089ee025291bca684e275329980fc7a2c
)co sieve.as

Compiling FriCAS source code from file
/dev/shm/hemmecke/fricas/b/src/input/sieve.as using Aldor
compiler and options
-O -Fasy -Flsp -lfricas -Y ../aldor/al -I
/home/hemmecke/backup/git/fricas-bisec
t/fricas/src/aldor/aldor
. Use the system command )set compiler args to change these
options.
Compiling Lisp source code from file sieve.lsp
Issuing )library command for sieve
Reading /dev/shm/hemmecke/fricas/b/src/input/sieve.asy


In 267c088620a7a088daa833a2e86e894ff094c7ee
)co sieve.as

Compiling FriCAS source code from file
/dev/shm/hemmecke/fricas/b/src/input/sieve.as using Aldor
compiler and options
-O -Fasy -Flsp -lfricas -Y ../aldor/al -I
/home/hemmecke/g/fricas-bisect/fricas/
src/aldor/aldor
. Use the system command )set compiler args to change these
options.

>> System error:
The variable |lsp| is unbound.

Continuing to read the file...

Unfortunately, I do not see, where this comes from. Why would moving
messages inline have anything to do with the success of the aldor
compilation?

commit 267c088620a7a088daa833a2e86e894ff094c7ee
Author: Waldek Hebisch <c...@fricas.org>
Date: Thu Mar 19 23:49:24 2026 +0100

Move more messages inline

Ralf

[Waldek Hebisch]

On Sat, Mar 21, 2026 at 08:33:56AM +0100, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:
> I think about this "target" directory later.
> We must first fix a regression.

Done.

That involved moving message printing code to a separate function.
Simple thing but needed variable was lost as a byproduct. BTW,
the whole change was very simple, but due to volume initially
there were several errors

--
Waldek Hebisch

[Ralf Hemmecke]

From a technical point of view, that looks OK.

However, I must question the existence of the target directory.
To me it sounds more like a local installation directory.

I understand its usefulness for collecting (and then distributing) the
pregenerated data. But otherwise (in the long run), I would rather like
to move away from having "target" at all.

If that patch comes with the reason for moving the aldor files
(in particular fricas.as and libfricas.al --- which are machine
independent) so that they can live in the pregenerated directory, then I
have no objection.

But then it makes sense to accompany this patch with more Makefile code for
(a) moving fricas.as and libfricas.al to the pre-generated distribution,
(b) only compiling the $runtime_files if libfricas.al is already in the
pre-generated directory.

That would indeed speed up from-source compilation in the presence of an
aldor compiler.

Since putting libfricas.al into fricas-x.y.z-full.tar.bz2 would make it
bigger by about 3MB, one could think of having an additional
fricas+aldor-x.y.z-full.tar.bz2.

Ralf