You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The goal of this ticket is to improve the suggestions about which packages should be installed on the system provided at the end of the ./configure. Often, it suggests to install a package which is already installed on the system. Let me explain it with an example based on the package sympow.
On Ubuntu 18.04, the version of sympow installed on the system with sudo apt install sympow is:
As understood in #30633, that version of sympow has an issue which is fixed upstream in version 2.023.6 available as a sage spkg. Therefore, sage will not use the sympow provided by the system anymore if some test of sympow fails, as shown below:
$ grep sympow config.log
## Checking whether SageMath should install SPKG sympow... ##
configure:32515: checking for sympow
configure:32533: found /usr/bin/sympow
configure:32545: result: /usr/bin/sympow
configure:32558: checking whether sympow works well (cf. :trac:30147 and :trac:30633)
configure:32565: result: no; cannot use system sympow
configure:32592: no suitable system package found for SPKG sympow
configure:38102: result: sympow-2.023.6: no suitable system package; will be installed as an SPKG
What I dislike is the suggestion that follows:
configure:39587: notice: the following SPKGs did not find equivalent system packages: _recommended boost ... sympow tox
configure:39587: checking for the package system in use
configure:39590: result: debian
configure:39599: hint: installing the following system packages is recommended and may avoid building some of the above SPKGs from source:
configure:39601: $ sudo apt-get update
$ sudo apt-get install ... sympow
It suggests me to install sympow! But it is already installed!
The reason for this bug is the definition of the variable SAGE_NEED_SYSTEM_PACKAGES in the file m4/sage_spkg_collect.m4 which is too inclusive in my opinion.
Let us start with the file build/pkgs/sympow/spkg-configure.m4 where the version of sympow (if available) is checked:
$ cat build/pkgs/sympow/spkg-configure.m4
SAGE_SPKG_CONFIGURE([sympow], [
AC_PATH_PROG([SYMPOW], [sympow])
AS_IF([test -z "$ac_cv_path_SYMPOW"], [sage_spkg_install_sympow=yes
], [
AC_MSG_CHECKING([whether sympow works well (cf. :trac:30147)])
sympow_rank_test=`echo "@<:@1,-1,0,-79,289@:>@" | sympow -analrank | grep ^"Analytic Rank is 4"`
AS_IF([test x"$sympow_rank_test" = x], [
AC_MSG_RESULT([no; cannot use system sympow])
sage_spkg_install_sympow=yes
], [
AC_MSG_RESULT([yes; use system sympow])
])
])
])
I am not so familiar with the m4 language, but as I understand the above the result is two-fold :
yes; use system sympow or
no; cannot use system sympow.
Instead, what it should return is three-fold:
yes; use system sympow
no; cannot find system sympow.
no; system sympow was found (version 1.023) but failed check requirements.
Notice that there are already two level of AS_IF in the above build/pkgs/sympow/spkg-configure.m4, so it should not be hard to fix.
After that, in the file m4/sage_spkg_collect.m4 the line
which appends the package name to the list SAGE_NEED_SYSTEM_PACKAGES when the result obtained from build/pkgs/sympow/spkg-configure.m4 is no should be fixed so that it appends it to the list only if the answer is no; cannot find system sympow.
Thus, the suggestions provided at the end of configure will be better. Moreover, the suggestions provided at the end could also give the list of packages that were installed but not suitable. That may need to create a new variable. I think that NOT_FOUND_SYSTEM_PACKAGES and FOUND_BUT_DECLINED_SYSTEM_PACKAGES would be good names for replacing the SAGE_NEED_SYSTEM_PACKAGES variable.
I am sorry I don't feel confident to edit the involved m4 files. I let this for others hoping they will agree with the above.
The goal of this ticket is to improve the suggestions about which packages should be installed on the system provided at the end of the
./configure
. Often, it suggests to install a package which is already installed on the system. Let me explain it with an example based on the package sympow.On Ubuntu 18.04, the version of
sympow
installed on the system withsudo apt install sympow
is:As understood in #30633, that version of sympow has an issue which is fixed upstream in version 2.023.6 available as a sage spkg. Therefore, sage will not use the
sympow
provided by the system anymore if some test of sympow fails, as shown below:What I dislike is the suggestion that follows:
It suggests me to install sympow! But it is already installed!
The reason for this bug is the definition of the variable SAGE_NEED_SYSTEM_PACKAGES in the file
m4/sage_spkg_collect.m4
which is too inclusive in my opinion.Let us start with the file
build/pkgs/sympow/spkg-configure.m4
where the version of sympow (if available) is checked:I am not so familiar with the m4 language, but as I understand the above the result is two-fold :
yes; use system sympow
orno; cannot use system sympow
.Instead, what it should return is three-fold:
yes; use system sympow
no; cannot find system sympow
.no; system sympow was found (version 1.023) but failed check requirements
.Notice that there are already two level of
AS_IF
in the abovebuild/pkgs/sympow/spkg-configure.m4
, so it should not be hard to fix.After that, in the file
m4/sage_spkg_collect.m4
the linewhich appends the package name to the list
SAGE_NEED_SYSTEM_PACKAGES
when the result obtained frombuild/pkgs/sympow/spkg-configure.m4
isno
should be fixed so that it appends it to the list only if the answer isno; cannot find system sympow
.Thus, the suggestions provided at the end of configure will be better. Moreover, the suggestions provided at the end could also give the list of packages that were installed but not suitable. That may need to create a new variable. I think that
NOT_FOUND_SYSTEM_PACKAGES
andFOUND_BUT_DECLINED_SYSTEM_PACKAGES
would be good names for replacing theSAGE_NEED_SYSTEM_PACKAGES
variable.I am sorry I don't feel confident to edit the involved m4 files. I let this for others hoping they will agree with the above.
CC: @slel @orlitzky
Component: build: configure
Issue created by migration from https://trac.sagemath.org/ticket/30863
The text was updated successfully, but these errors were encountered: