-
-
Notifications
You must be signed in to change notification settings - Fork 452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
don't always force build of givaro+fflas_ffpack if linbox must be built #37348
Comments
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? |
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). |
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. |
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. |
Well, we also have an upgrade PR here: #35148 But there were too many problems, revealed by... surprise! ... platform testing. |
hmm, I thought we stopped supporting x86 (32 bit), no? (which was the reason not to upgrade). I'd be for it. |
https://github.com/sagemath/sage/wiki/Sage-10.3-Release-Tour#sources has the supported platforms. |
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 |
let's drop x86 in Sage 10.4. It's not worth the trouble to keep it. |
-1 on doing platform support decisions randomly like that. 32bit is coming back big time with WASM. #34539 |
by the time all the essential Sage components will run on wasm, it will be wasm64. |
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). |
This argument goes both ways - then not all parts need to be runnable on an 32-bit arch, either. |
That's right, only the ones that wants to run. |
In #36997 the change
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.
The text was updated successfully, but these errors were encountered: