spkg-configure.m4 for sympow

[Dima Pasechnik]

this should be easy, just binaries (and possibly data, tbd)

in Debian it's sympow and (maybe needed) sympow-data

[Dima Pasechnik]

New commits:

​2113187

spkg-configure for sympow

[Michael Orlitzky]

Works for me with the sympow fork. As of five minutes ago, this is sci-mathematics/sympow in Gentoo. Can you add that to gentoo.txt?

My only other question is why you settled on testing $ac_cv_path_SYMPOW instead of just $SYMPOW? The name of that cache variable is documented, so it should work just as well, but it was surprising to me.

[git]

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

​f36ccba	spkg-configure for sympow
​99ebe04	add gentoo package name

[Dima Pasechnik]

Added gentoo info.

Regarding SYMPOW vs ac_cv_path_SYMPOW, the latter seems to be what we normally use in many other spkg-configure.m4 files.

It appears that using SYMPOW is more hacky, e.g. if it's set then the test is not carried out, etc. E.g. if it's set to something not in PATH, it will probably not be found later on by sagelib.

[Michael Orlitzky]

Replying to dimpase:

It appears that using SYMPOW is more hacky, e.g. if it's set then the test is not carried out, etc. E.g. if it's set to something not in PATH, it will probably not be found later on by sagelib.

You mean if the user exports SYMPOW="junk or some non-PATH location"? I think the only reason ac_cv_path_SYMPOW avoids that same problem is because of the ugly variable name. Instead of SYMPOW we could use e.g. SAGE_SYMPOW_PATH or something like that to the same end.

In another life, we could make overrides work with e.g. --with-sympow=/home/mjo/bin/sympow but I think we all have better things to do right now.

[Dima Pasechnik]

Replying to mjo:

Replying to dimpase:

It appears that using SYMPOW is more hacky, e.g. if it's set then the test is not carried out, etc. E.g. if it's set to something not in PATH, it will probably not be found later on by sagelib.

You mean if the user exports SYMPOW="junk or some non-PATH location"? I think the only reason ac_cv_path_SYMPOW avoids that same problem is because of the ugly variable name. Instead of SYMPOW we could use e.g. SAGE_SYMPOW_PATH or something like that to the same end.

Autoconf docs are silent on what happens if ac_cv_path_SYMPOW is pre-set, so it appears to be more robust.

Thanks for review!

[Michael Orlitzky]

Replying to dimpase:

Autoconf docs are silent on what happens if ac_cv_path_SYMPOW is pre-set, so it appears to be more robust.

I can't find any explicit docs, but as a cache variable, it does what you'd expect: the configure script first tests the value of ac_cv_path_SYMPOW, and if it's set, its value gets used in lieu of the check:

if ${ac_cv_path_SYMPOW+:} false; then :
  $as_echo_n "(cached) " >&6
else
  # the check gets run and ac_cv_path_SYMPOW is populated
fi
SYMPOW=$ac_cv_path_SYMPOW

[Matthias Köppe]

Follow-up: It looks like this accepts a broken sympow on fedora-32 - #3360

[Matthias Köppe]

Also with sympow on ubuntu-bionic-standard (​https://github.com/mkoeppe/sage/runs/867730944)

[Matthias Köppe]

also fedora-28-standard (​https://github.com/mkoeppe/sage/runs/867731144)

[Matthias Köppe]

I've opened #30147 (Fix spkg-configure.m4 for sympow) for this. Please fix!