spkg-configure.m4 for m4ri, m4rie, givaro

[dimpase]

these are very straightforward, basically just doing dependencies and version checks.

m4ri(e) are quite stable, and it appears impossibe to distinguish the present version of m4rie from the older one. We just rely on the version of m4ri, it's dependence, which thankfully has pkg-config support.

[dimpase]

see ​https://bitbucket.org/malb/m4rie/issues/18/add-pkg-config-support

[dimpase]

this is quite straighforward w.r.t. to m4ri(e) and givaro spkg-configure files, less so with a macro to check dependencies that I wrote and used on these examples. Please review.

---

New commits:

​283e64a

macro SAGE_SPKG_DEPCHECK, to test for dependencies:

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​4e1d00e

SAGE_SPKG_DEPCHECK, spkg-configure for m4ri(e), givaro

[dimpase]

One improvement for SAGE_SPKG_DEPCHECK would be to get rid of the 1st argument, the package name. After all it is called from within SAGE_SPKG_CONFIGURE, and the package name should be "known", but I have no clue how to get it.

[isuruf]

This works for me on conda. Somebody else should review the macro.

[embray]

Replying to dimpase:

One improvement for SAGE_SPKG_DEPCHECK would be to get rid of the 1st argument, the package name. After all it is called from within SAGE_SPKG_CONFIGURE, and the package name should be "known", but I have no clue how to get it.

If it's only used within SAGE_SPKG_CONFIGURE it can probably use the SPKG_NAME macro. But I think it's maybe a bit cleaner actually to keep it more independent.

[dimpase]

Already working on this ticket I made an error involving the 1st parameter of SAGE_SPKG_DEPCHECK, as I copy-pasted it and didn't adjust is :-)

As we should eventually rewrite already done 20 or 30 spkg-configure.4 files using this macro, it's better to minimise the number of places one can make this sort of error...

[embray]

I think a typo in SAGE_SPKG_DEPCHECK:

AC_DEFUN([SAGE_SPKG_DEPCHECK], [
+    m4_foreach_w([DEP], $2, [
+       AC_REQUIRE([SAGE_SPKG_CONFIGURE_]m4_toupper(DEP))])
+    AC_MSG_CHECKING([installing $2? ])
+    AS_IF([test x = y m4_foreach_w([DEP], $2, [ -o [x$sage_spkg_install_]DEP = x$yes])],

At the end of the last line I think you just meant xyes not x$yes.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​3bf2069	remove spurious '$'
​0fa8a4d	update lists of packages which can be useful for installation
​afacd43	remove unneeded parameter, use SPKG_NAME instead

[dimpase]

OK, fixed that embarassing extra $, and further improvements (see commits). Needs review.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​21d6aa5

mention lcalc system packages (prepare for #28224)

[embray]

I don't really think ​afacd43 is much of an improvement. To me it looks fragile and potentially confusing. But I won't fight it for now, as long as it works, if you really think it's better...

[embray]

The m4ri in my (old-ish) Ubuntu is too old to otherwise test this.

I had a container with a newer Ubuntu but it seems to have gone away. I'll set that up again, but in the meantime I think this looks good assuming it works at least on your system.

[dimpase]

you may try installing m4ri(e) in /usr/local/, for testing.

certainly the new macro should have been a part of sage_spkg_configure() all along, getting rid of one parameter is a step towards this refactoring...

[embray]

I got a new Ubuntu 18.04 container set up and it worked! :)

[dimpase]

It seems something wasn't fully tested w.r.t. #26932, and in fact this needs

build/pkgs/givaro/spkg-configure.m4

@@ -1 +1 @@
 SAGE_SPKG_CONFIGURE([givaro], [
-    m4_pushdef([SAGE_GIVARO_MINVER],["40004"])
+    m4_pushdef([SAGE_GIVARO_MINVER],["40101"])
     SAGE_SPKG_DEPCHECK([gmp mpir], [
         AC_PATH_PROG([GIVAROCONFIG], [givaro-config])
         AS_IF([test x$GIVAROCONFIG = x], [

I've opened #28380 to fix this.