don't always force build of givaro+fflas_ffpack if linbox must be built

[dimpase]

In #36997 the change

db7703c47b27 (Matthias Koeppe  2024-01-02 18:54:05 -0800 11) ], [dnl REQUIRED_CHECK
db7703c47b27 (Matthias Koeppe  2024-01-02 18:54:05 -0800 12) ], [dnl PRE
db7703c47b27 (Matthias Koeppe  2024-01-02 18:54:05 -0800 13) ], [dnl POST
db7703c47b27 (Matthias Koeppe  2024-01-02 18:54:05 -0800 14)    sage_spkg_install_fflas_ffpack=$sage_spkg_install_linbox
db7703c47b27 (Matthias Koeppe  2024-01-02 18:54:05 -0800 15)    sage_spkg_install_givaro=$sage_spkg_install_linbox

has broken the case where givaro and/or fflas_ffpack from the system are OK, but linbox is not.

If the "old" set of givaro+fflas_ffpack is OK, but linbox is not, then only linbox ought to be built, not the whole trio.

This might not the case for the "new" set, as our linbox is probably too old to use "new" givaro+fflas_ffpack.

[dimpase]

@mkoeppe

[mkoeppe]

This might not the case for the "new" set, as our linbox is probably too old to use "new" givaro+fflas_ffpack.

That's right, our linbox is too old for that!

Do you really care about systems that carry the old versions only, and moreover only a subset of them?

[tornaria]

FWIW, the givaro+fflas+linbox trio needs to be an exact matching set of versions, this is known as "modularization" (@mkoeppe just half-joking 🤣). It seems it might lead to trouble to try to build spkg linbox with system givaro+fflas. Also, there's patching involved, I'm carrying patches that are in upstream github since sep 2021 and haven't been released, and I'm not sure linbox builds with unpatched fflas, etc.

This is the type of pain you inflict on downstream when you cut a project in pieces but all of them have to be exactly matching (sage is better in the "upstreaming patches" department, although sometimes one has to push).

[dimpase]

carrying patches that are in upstream github since sep 2021 and haven't been released

Gentoo recently updated givaro+fflas_ffpack+linbox to the new versions, and there aren't any tricky patches (a test is removed, and few things in configuration touched).

Well, if they are in real life coming in trios, let it be, but we should not make it look like it's a bug in ./configure when you see givaro and fflas_ffpack first accepted, and then rejected together with linbox.

It should be made clear by looking at config.log that it happens for a reason, and not due to an error in m4 code.

[mkoeppe]

we should not make it look like it's a bug in ./configure when you see givaro and fflas_ffpack first accepted, and then rejected together with linbox.

I'll be happy to review a PR that adds some messages that explain this.

I'll also be happy to review a PR that accepts an incomplete set of OLD versions, matching our OLD SPKG versions. Obviously I could have implemented that, but it didn't have enough priority.

[mkoeppe]

gentoo recently updated givaro+fflas_ffpack+linbox to the new versions, and there aren't any tricky patches

Well, we also have an upgrade PR here: #35148

But there were too many problems, revealed by... surprise! ... platform testing.
Upstream has merged my PR that uses the Sage CI for platform testing linbox-team/fflas-ffpack#386, but has so far not addressed any of the opened issues: https://github.com/linbox-team/fflas-ffpack/issues

[dimpase]

hmm, I thought we stopped supporting x86 (32 bit), no? (which was the reason not to upgrade).

I'd be for it.

[mkoeppe]

https://github.com/sagemath/sage/wiki/Sage-10.3-Release-Tour#sources has the supported platforms.

[mkoeppe]

You can also look up this info in the new-and-improved section https://deploy-livedoc--sagemath.netlify.app/html/en/developer/portability_testing#using-our-pre-built-docker-images-published-on-ghcr-io

[dimpase]

let's drop x86 in Sage 10.4. It's not worth the trouble to keep it.

[mkoeppe]

-1 on doing platform support decisions randomly like that.

32bit is coming back big time with WASM. #34539

[dimpase]

by the time all the essential Sage components will run on wasm, it will be wasm64.

[mkoeppe]

With the modularization of the Sage library, one does not have to wait for "all essential components" to be ready to build something useful; so one does not even have to wait for wasm33 (= one more bit).

[dimpase]

This argument goes both ways - then not all parts need to be runnable on an 32-bit arch, either.

[mkoeppe]

That's right, only the ones that wants to run.