Output of fricas startup script: version

[Grégory Vanuxem]

Hello,

I need to parse the output of the fricas startup script to eventually
know which version is installed . Actually, the first line of 'fricas
--version' is different whether X is supported or not:
└─$ fricas --version
viewman not present, disabling graphics
hypertex not present, disabling
FriCAS 2023-06-17
based on sbcl 2.3.6

└─$ /usr/local/bin/fricas --version
FriCAS 2023-06-17
based on openmcl 1.12.1

┌──(greg㉿ellipse)-[~]
└─$

What about putting the FriCAS version on the first line whether or not
X is supported?
__
Greg

[Waldek Hebisch]

Version information is printed by FriCASsys. The messages you see
are warnings from fricas script. If they appear at all they will
appear before startup of FriCASsys.

--
Waldek Hebisch

[Grégory Vanuxem]

Hello Waldek,

Le sam. 29 juil. 2023 à 20:32, Waldek Hebisch
<de...@fricas.math.uni.wroc.pl> a écrit :
>
[snippet]

> > What about putting the FriCAS version on the first line whether or not
> > X is supported?
>
> Version information is printed by FriCASsys. The messages you see
> are warnings from fricas script. If they appear at all they will
> appear before startup of FriCASsys.

From the fricas script it appears to me that version information,
FRICAS environment variable and so on are prepended to src/etc/fricas.
They are determined at configure time with the different possible
options, so I would suggest moving the part that checks viewman and
hyperdoc at the end of the script. Moreover, errors in parameters to
the fricas script, displaying help or version messages should not let
the user be aware of the unavailability of those binaries. Below is a
simple patch that moves to the end of the fricas script this part. I
put it before the '-nogo' option in such a way that showing what would
be executed displays this unavailability if this is the case.

$ cat fricas.diff
--- src/etc/fricas.old 2023-07-30 15:05:09.551404486 +0200
+++ src/etc/fricas 2023-07-30 15:20:29.491405181 +0200
@@ -128,17 +128,6 @@

otheropts=""

-if [ ! -f $FRICAS/lib/viewman ] ; then
- echo "viewman not present, disabling graphics"
- otheropts="-nogr"
-fi
-
-if [ ! -f $FRICAS/bin/hypertex ]; then
- echo "hypertex not present, disabling"
- otheropts="$otheropts -noht"
-fi
-
-
while [ "$*" != "" ] ; do
opt=$1
case $1 in
@@ -226,7 +215,15 @@
ciao
fi

-# 6. Start processes
+if [ ! -f $FRICAS/lib/viewman ] ; then
+ echo "viewman not present, disabling graphics"
+ otheropts="-nogr $otheropts"
+fi
+
+if [ ! -f $FRICAS/bin/hypertex ]; then
+ echo "hypertex not present, disabling"
+ otheropts="-noht $otheropts"
+fi

if [ $go = no ] ; then
echo "Would now execute the following."
@@ -236,4 +233,6 @@
exit 0
fi

+# 6. Start processes
+
eval "exec $FRICAS/bin/sman $otheropts -ws $serverws"

=====================================================
Regards,
__
Greg

[Ralf Hemmecke]

>> What about putting the FriCAS version on the first line whether or not
>> X is supported?
>
> Version information is printed by FriCASsys. The messages you see
> are warnings from fricas script. If they appear at all they will
> appear before startup of FriCASsys.

Would it be an option to send the output of the lines

################
if [ ! -f $FRICAS/lib/viewman ] ; then
echo "viewman not present, disabling graphics"
otheropts="-nogr"
fi

if [ ! -f $FRICAS/bin/hypertex ]; then

echo "hypertex not present, disabling"

otheropts="$otheropts -noht"
fi
################

to stdout?

Otherwise I agree with Greg that "fricas --version" should give the
version information in the first two lines.

Ralf

[Grégory Vanuxem]

Hello, Ralf, Waldek, *,

Thanks Ralf for supporting this proposal.

I'm used to run different FriCAS versions at the same time and since I
plan to support this in a FriCAS personal plugin for VSCode (not
published yet), I need version informations to populate my
'FriCASExecutable' computational "structure". For now 'fricas
--version' is inconsistent to me. But this is usual apparently even
with Common Lisp implementations. For example, 'gcl --version' gives:

$gcl --version
GCL 2.6.14 ...

whereas in GCL
>(lisp-implementation-type)
"GNU Common Lisp (GCL)"

Clozure CL is more consistent from my point of view:
└─$ /home/greg/.roswell/impls/x86-64/linux/ccl-bin/1.12.2/lx86cl64 --version
Clozure Common Lisp Version 1.12.2 (v1.12.2) LinuxX8664

and in it:
CCL is free software. It is distributed under the terms of the Apache
Licence, Version 2.0.
? (lisp-implementation-type)
"Clozure Common Lisp"
?

After, that is just a matter of opinion I guess.
By the way, if there is some interest I filed a pull request,
https://github.com/fricas/fricas/pull/134

The original code is in https://github.com/gvanuxem/fricas/tree/fricas-version
(the fricas-version branch) for an eventual 'diff'. I will keep one
since I will delete this branch in the near future.

Regards,
__
Greg

> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/b4b97c50-2550-ec63-3b28-f460932ebdda%40hemmecke.org.

[Tim Daly]

Version numbering is a hotly debated issue no-one can agree on.

To get a reliable, repeatable "version" that also allows debugging

use git's sha1 hash.

[Grégory Vanuxem]

Order matters.

Try to avoid :https://en.wikipedia.org/wiki/Mathematical_induction

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/b3ef935f-b3ec-4fdd-863e-a3e4929b1bf4n%40googlegroups.com.

[Tim Daly]

-- Order matters

It does.

Axiom uses a day/date/time format specifically to show order.

My startup header shows the month of release and when

this running code was built from that release:

   Version: Axiom (May 2016)

   Timestamp: Friday February 8, 2019 at 05:35:41

The git hash is embedded to specifically identify the related code.

In the PDF generated from literate source you'll see the date and hash.

For example, from the Axiom Wikipedia page PDF for the Jenks book:

20210107 7beff147070c2fd433caddc60932eecd30ca28c3

At this point you have all useful, exact information.

For some odd reason, version coding generates a lot of heat.

I really didn't intend to restart that debate.

You received this message because you are subscribed to a topic in the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fricas-devel/nCmITgebc7I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fricas-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2daBDxBOUvy5ZZJngGsjJKK8GvjgZD_TwnMFRo0xtAk22w%40mail.gmail.com.

[Grégory Vanuxem]

It was a joke of course. 

__
Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAJn5L%3D%2B25aXEY03irCRH7UGpxGCyk3aUAZLUtYmQUhUZWHcdLA%40mail.gmail.com.

[Grégory Vanuxem]

__
Greg

Le dim. 27 août 2023, 20:10, Tim Daly <axio...@gmail.com> a écrit :

-- Order matters

It does.

Axiom uses a day/date/time format specifically to show order.

My startup header shows the month of release and when

this running code was built from that release:

   Version: Axiom (May 2016)

   Timestamp: Friday February 8, 2019 at 05:35:41

The git hash is embedded to specifically identify the related code.

In the PDF generated from literate source you'll see the date and hash.

For example, from the Axiom Wikipedia page PDF for the Jenks book:

20210107 7beff147070c2fd433caddc60932eecd30ca28c3

At this point you have all useful, exact information.

For some odd reason, version coding generates a lot of heat.

I really didn't intend to restart that debate

Sorry. I hate. It was not my attend. 

Confused. 

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAJn5L%3D%2B25aXEY03irCRH7UGpxGCyk3aUAZLUtYmQUhUZWHcdLA%40mail.gmail.com.

[Waldek Hebisch]

Dnia Tue, Aug 22, 2023 at 08:03:50AM +0200, Grégory Vanuxem napisał(a):
> Hello, Ralf, Waldek, *,
>
> Thanks Ralf for supporting this proposal.
>
> I'm used to run different FriCAS versions at the same time and since I
> plan to support this in a FriCAS personal plugin for VSCode (not
> published yet), I need version informations to populate my
> 'FriCASExecutable' computational "structure". For now 'fricas
> --version' is inconsistent to me. But this is usual apparently even
> with Common Lisp implementations. For example, 'gcl --version' gives:
>
> $gcl --version
> GCL 2.6.14 ...
>
> whereas in GCL
> >(lisp-implementation-type)
> "GNU Common Lisp (GCL)"
>
> Clozure CL is more consistent from my point of view:

> =E2=94=94=E2=94=80$ /home/greg/.roswell/impls/x86-64/linux/ccl-bin/1.12.2/l=

> x86cl64 --version
> Clozure Common Lisp Version 1.12.2 (v1.12.2) LinuxX8664
>
> and in it:
> CCL is free software. It is distributed under the terms of the Apache
> Licence, Version 2.0.
> ? (lisp-implementation-type)
> "Clozure Common Lisp"
> ?
>
> After, that is just a matter of opinion I guess.
> By the way, if there is some interest I filed a pull request,
> https://github.com/fricas/fricas/pull/134
>

> The original code is in https://github.com/gvanuxem/fricas/tree/fricas-vers=

> ion
> (the fricas-version branch) for an eventual 'diff'. I will keep one
> since I will delete this branch in the near future.

Moving tests so that '--version' is handled before possible error
messages is fine. However, other changes look like regression to
me: current tests in 'config.lisp' deliberately match feature
tests in Lisp code. Since "features" are used by programs they
should be more stable than other things. Basing test on output
that is normally _not_ handled by programs is less robust.
And there is added uglyness due to embedded spaces in messages.

--
Waldek Hebisch

[Grégory Vanuxem]

Yes I agree. Not a necessary addition.

And to add, not a Git specialist. Too a lot of errors with me. But that's the way. 

__
Greg

--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZPB02N9%2BKileYdrU%40mail.math.uni.wroc.pl.

[Dima Pasechnik]

What's important is to provide a painless for the user way to get the version, and possibly more (e.g. the underlying Lisp). 

That's because what upstreams, such as SageMath, often need to know.

I'd propose to add the version support via pkg-config. If this is OK, I'd provide a PR for this.

pkg-config would output the version in an easily parceable format, so that one would not need to call sed to santitize the output of

fricas --version

Dima

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2daHSrLZY9Wz61r_XuM7%3DmJzRB_k8uo-u4HK5UUPvJvYOw%40mail.gmail.com.

[Ralf Hemmecke]

Hi Oima,

> I'd propose to add the version support via pkg-config. If this is OK, I'd
> provide a PR for this.
>
> pkg-config would output the version in an easily parceable format, so that
> one would not need to call sed to santitize the output of
>
> fricas --version

I cannot say whether the pkg-config stuff will make it into frica, but I
would love to see how it works. Would it cost you too much effort to
create such a PR?

How is the underlying LISP recognized by pkg-config.

Otherwise, I do as Waldek proposed and single out the --version option
to simply output the fricas and lisp version and exit when it appears on
the command line of the fricas script.

Ralf

[Dima Pasechnik]

On Fri, Sep 1, 2023 at 11:51 PM Ralf Hemmecke <ra...@hemmecke.org> wrote:

> > I'd propose to add the version support via pkg-config. If this is OK, I'd
> > provide a PR for this.
> >
> > pkg-config would output the version in an easily parceable format, so that
> > one would not need to call sed to santitize the output of
> >
> > fricas --version
>
> I cannot say whether the pkg-config stuff will make it into frica, but I
> would love to see how it works. Would it cost you too much effort to
> create such a PR?

it's not clear to me what the FriCAS version is meant to be. Is it
PACKAGE_VERSION='2023-06-17' (in the current git master)

>
> How is the underlying LISP recognized by pkg-config.

it's all very easy - one creates a template file fricas.pc.in with the
values filled in by ./configure, which writes fricas.pc
The latter is then installed by "make install" (does FriCAS have
install target in the main
Makefile?) into $prefix/lib/pkgconfig/

Then pkg-config reads fricas.pc when called, and prints the values it
is asked for. E.g. using GMP as
an example:

$ pkg-config --modversion gmp # GMP version
6.2.1
$ pkg-config --libs gmp # GMP libraries/flags fotr the linker
-lgmp

etc.

it allows custom fields to be added to fricas.pc, so it's easy to
fill/queue these, too, e.g. for the LIsp
name and Lisp version in the case of FriCAS.

$ pkg-config --print-variables gmp # show all the variable defined for GMP
exec_prefix
includedir
libdir
pcfiledir
prefix
$ pkg-config --variable=libdir gmp # print the value of libdir variable
/usr/lib/x86_64-linux-gnu

etc.



HTH
Dima

>
> Otherwise, I do as Waldek proposed and single out the --version option
> to simply output the fricas and lisp version and exit when it appears on
> the command line of the fricas script.
>
> Ralf
>

> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/931beec1-a2c4-3be2-7198-87d9fc86136c%40hemmecke.org.

[Waldek Hebisch]

Dnia Sat, Sep 02, 2023 at 12:39:40AM +0300, Dima Pasechnik napisał(a):
> On Fri, Sep 1, 2023 at 11:51=E2=80=AFPM Ralf Hemmecke <ra...@hemmecke.org> w=
> rote:
>
> > > I'd propose to add the version support via pkg-config. If this is OK, I=

> 'd
> > > provide a PR for this.
> > >

> > > pkg-config would output the version in an easily parceable format, so t=

> hat
> > > one would not need to call sed to santitize the output of
> > >
> > > fricas --version
> >
> > I cannot say whether the pkg-config stuff will make it into frica, but I
> > would love to see how it works. Would it cost you too much effort to
> > create such a PR?
>
> it's not clear to me what the FriCAS version is meant to be. Is it

> PACKAGE_VERSION=3D'2023-06-17' (in the current git master)

In git repo this is date of last modification of configure.ac.
Releases get three part version number with parts separated
by dots. So it is easy to distinguish releases from git
snapshots, but meaning is different. OTOH it _not_ expected
that anybody will depend on version numbers from git...

> >
> > How is the underlying LISP recognized by pkg-config.
>
> it's all very easy - one creates a template file fricas.pc.in with the
> values filled in by ./configure, which writes fricas.pc
> The latter is then installed by "make install" (does FriCAS have
> install target in the main
> Makefile?) into $prefix/lib/pkgconfig/

There is 'install' target.

> Then pkg-config reads fricas.pc when called, and prints the values it
> is asked for. E.g. using GMP as
> an example:
>
> $ pkg-config --modversion gmp # GMP version
> 6.2.1
> $ pkg-config --libs gmp # GMP libraries/flags fotr the linker
> -lgmp
>
> etc.
>
> it allows custom fields to be added to fricas.pc, so it's easy to
> fill/queue these, too, e.g. for the LIsp
> name and Lisp version in the case of FriCAS.
>
> $ pkg-config --print-variables gmp # show all the variable defined for GMP
> exec_prefix
> includedir
> libdir
> pcfiledir
> prefix

> $ pkg-config --variable=3Dlibdir gmp # print the value of libdir variable
> /usr/lib/x86_64-linux-gnu
>
> etc.

Looks OK. But AFAICS 'pkg-config' support is really additional to
'--version'. So change to '--version' should go on.

--
Waldek Hebisch

[Grégory Vanuxem]

Hello Dima,

I agree with you, Dima, about the usefulness of pkg-config and I am
not surprised the SAGE Team uses it; they incorporate tons of external
libraries.

<digression>
In fact I discovered this utility some time ago, at the beginning of
Gnome 2 development. I thought this utility was developed by this team
since from my point of view at that time this is the team who really
popularised this utility. I used it because I needed a quick image
visualisator, 'eog' was becoming too library dependent, too large and
too long to start to just see a pic. I have been doing photography for
many years and to visualise pics I do not need a lot of functionality.
The Evas library from DR16 (Enlightenment window manager) started to
use this utility and was useful to me to have linker arguments,
cflags, say -DSOMETHING=1, and eventually the include path.
</digression>

But I see this application as an utility to know
*settings/configuration* about a library, and now some applications,
more than to know the version or (quick) help of an application. For
example on my computer I have in /usr/share/pkg-config/ 'fontutil.pc'
which contains:

prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu
datarootdir=${prefix}/share
datadir=${datarootdir}
fontrootdir=${datadir}/fonts/X11
mapdir=${prefix}/share/fonts/X11/util

Name: FontUtil
Description: Font utilities dirs
Version: 1.3.1

I agree that the Name, Description and Version information could be
useful, particularly for my needs, but its primary purpose is to
display informations above in this file for me. To add to this, I do
not even have the pkg-config or pkgconf package installed. I do not
need them as of now. I totally agree with the package description:
===========================================================
Description: manage compile and link flags for libraries (transitional package)
pkgconf is an implementation of the pkg-config system, which helps to configure
compiler and linker flags for development frameworks.
.
pkgconf is a replacement for pkg-config, providing additional functionality
while also maintaining compatibility.
.
This package only provides a dependency link to the pkgconf package to help
with package upgrades. It can be safely removed.
Description-md5: df0bd7e16369ac7330df23f92a214b3a
Multi-Arch: same
Homepage: http://pkgconf.org/
Tag: admin::configuring, devel::buildtools, interface::commandline,
role::program, scope::utility
Section: devel
============================================================

So, yes, why not use this utility to display some information about
FriCAS, even if I do not see a lot of information to write in it, I
would prefer to keep version information available from the 'fricas'
executable as you suggest I guess (but add a pkg-config file).
Personally I would also prefer to add to the fricas script the ability
to execute code and return to the shell. As of now 'fricas -eval'
executes code at startup but does not leave the fricas REPL. What
could also be useful is something like:
└─$ perl -e 'print 2+2'
4
┌──(greg㉿ellipse)-[~]
└─$ python3 -c 'print(2+2)'
4

┌──(greg㉿ellipse)-[~]
└─$ julia -e 'print(2+2)'
4
etc. (read a file also, why not)

That way I could use, say, 'fricas -c ')lisp
(lisp-implementation-type)' or other things. This information is
already in the fricas startup script though, it is just an example.

By the way I attached the primary patch, as an illustration, that just
moves the code related to HyperDoc and Graphics availability.

__
Greg

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq07TtLc4%3DPB0orTjZT3eRiU0e_Fvqw8ziWyN9PpfVP0rg%40mail.gmail.com.

[Dima Pasechnik]

applications/systems which have ability to call external command line executables have interfaces to pkg-config.

E.g. there is a Python pkgconfig module.

There are also autoconf macros to call pkg-config. And cmake, too.

So it's, by far, not limited to libraries.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dY445y34scW5UkoqoCOTJ6PeGzkiXp%3DqVp1zcmrOjg6Yw%40mail.gmail.com.

[Dima Pasechnik]

On Sat, 2 Sept 2023, 15:11 Waldek Hebisch, <de...@fricas.math.uni.wroc.pl> wrote:

Dnia Sat, Sep 02, 2023 at 12:39:40AM +0300, Dima Pasechnik napisał(a):
> On Fri, Sep 1, 2023 at 11:51=E2=80=AFPM Ralf Hemmecke <ra...@hemmecke.org> w=
> rote:
>
> > > I'd propose to add the version support via pkg-config. If this is OK, I=
> 'd
> > > provide a PR for this.
> > >
> > > pkg-config would output the version in an easily parceable format, so t=
> hat
> > > one would not need to call sed to santitize the output of
> > >
> > > fricas --version
> >
> > I cannot say whether the pkg-config stuff will make it into frica, but I
> > would love to see how it works. Would it cost you too much effort to
> > create such a PR?
>
> it's not clear to me what the FriCAS version is meant to be. Is it
> PACKAGE_VERSION=3D'2023-06-17' (in the current git master)

In git repo this is date of last modification of configure.ac.
Releases get three part version number with parts separated
by dots.  So it is easy to distinguish releases from git
snapshots, but meaning is different.  OTOH it _not_ expected
that anybody will depend on version numbers from git...

So, what is the variable in configure.ac to use 

to get the version?

As you check in ./configure (is it always unmodified output of autoconf?) in the repo, it's impossible to be sure.

--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZPMmeWm9m0I13zOl%40mail.math.uni.wroc.pl.

[Grégory Vanuxem]

I was not aware of that. Thanks. And in fact I just discovered yesterday the *. pc files for executables. I do not say it's of no use. 

__
Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq0OvnSUkc6KXApmwgifLLeAz%2BpuNHDsnqL4e4je8jBHxw%40mail.gmail.com.

[Ralf Hemmecke]

> So, what is the variable in configure.ac to use
> to get the version?

For FriCAS itself, it is set through AC_INIT.

https://github.com/fricas/fricas/blob/master/configure.ac#L2

AC_INIT([FriCAS], [2023-06-17],
[fricas...@googlegroups.com],
[fricas],
[https://fricas.github.io])

https://github.com/fricas/fricas/blob/r1.3.9/configure.ac#L2

AC_INIT([FriCAS], [1.3.9],
[fricas...@googlegroups.com],
[fricas],
[https://fricas.github.io])

The Lisp, version is another thing. That is computed at configure time
and naturally depends on the options an what is available on the system.

It is put at configure time into

$fricas_lisp_flavor
$fricas_lisp_version

In the Makefile it is available in variables with all capital letters.

https://github.com/fricas/fricas/blob/master/config/var-def.mk

Ralf

[Dima Pasechnik]

On Mon, 4 Sept 2023, 09:29 Ralf Hemmecke, <ra...@hemmecke.org> wrote:

> So, what is the variable in configure.ac to use
> to get the version?

For FriCAS itself, it is set through AC_INIT.

https://github.com/fricas/fricas/blob/master/configure.ac#L2

AC_INIT([FriCAS], [2023-06-17],
         [fricas...@googlegroups.com],
         [fricas],
         [https://fricas.github.io])

https://github.com/fricas/fricas/blob/r1.3.9/configure.ac#L2

AC_INIT([FriCAS], [1.3.9],
         [fricas...@googlegroups.com],
         [fricas],
         [https://fricas.github.io])

The Lisp, version is another thing. That is computed at configure time
and naturally depends on the options an what is available on the system.

It is put at configure time into

   $fricas_lisp_flavor
   $fricas_lisp_version

I am asking as, unlike any other autoconfed project, FriCAS does not seem to have a dedicated version variable.

Should one use PACKAGE_VERSION (this is what the documentation of AC_INIT says - it writes there the value of the 2nd parameter) ?

Something else?

In the Makefile it is available in variables with all capital letters.

https://github.com/fricas/fricas/blob/master/config/var-def.mk

Ralf

--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ac0f2bd0-181b-60c2-566b-5f43914a0132%40hemmecke.org.

[Waldek Hebisch]

There is Makefile variable VERSION which takes value from configure
PACKAGE_STRING, this is used by main FriCAS executable. You
probably want version alone, without package name, that is
PACKAGE_VERSION both in configure and in Makefile-s.

--
Waldek Hebisch

[Grégory Vanuxem]

Le jeu. 31 août 2023, 13:09, Waldek Hebisch <de...@fricas.math.uni.wroc.pl> a écrit :

> The original code is in https://github.com/gvanuxem/fricas/tree/fricas-vers=
> ion
> (the fricas-version branch) for an eventual 'diff'. I will keep one
> since I will delete t

And there is added uglyness due to embedded spaces in messages.

If it was for the pseudo patches sent, fixed in my 'vi' configuration. I knew I had to change that.

Thanks!

__

Greg