On 2025-04-21 19:41:35, Marc Culler wrote:
>
> Except that it is impossible for the newly-built python to be linked
> against the
> sage copies of those libs, because the hewly-built python needs to be built
> *before* sage is built, and therefore before those libs have been built.
The sage build process actually involves two versions of python. One
is used as part of the build process, and another is built (and later
used) to run sage.
The first one is quietly mentioned as part of the _prereq package and
has very few constraints. It's the one that is built for later use
with sage that needs to have all of its libraries be compatible with
everything else.
> That python must be accompanied by all of those other libraries and
> then sage must also use the same libraries. One way to do that
> might be to modify the sage build process so that it builds the
> spkgs for those libraries and then is forced to halt while a
> separate python compilation is done in such a way that the python
> modules which use those libraries can be linked against the versions
> which were built by the corresponding sage spkgs. The sage build
> process could perhaps then be restarted to build the rest of sage.
Yes, you would have to build those libraries first before building the
python that will eventually be used with sage. But the python used to
invoke the build system up to that point can be arbitrary.
It will be a headache.
The ./configure option to re-enable python is a good compromise.
*Eventually* you should have your own build scripts for the system
stuff, but in the meantime, the two goals that I can personally take
ownership of are,
1. I don't think end users should ever be trying to build python; if
they get that far, some other error has likely compounded. It
would be much better to suggest that they find a suitable system
python (and bzip2, and liblzma, etc.) instead.
2. Largely as a result of the first item, I don't want to maintain
the python SPKG, e.g. be forced to upgrade the python SPKG and
mess with ./bootstrap and ./configure whenever we make changes
to sagelib.
In our current example, removing python on its own does not perfectly
address the first item, because it's still possible that users could
build the liblzma SPKG, and in that case, the system python would be
linked to some other version of liblzma. The sage build system thinks
this is an error (and in some cases it probably is). To rectify it, we
should also insist that zlib, bzip2, libffi, and liblzma come from the
system -- in other words, we should disable those SPKGs too. I have a
feeling that this would be a lot more politically viable if we left
behind a ./configure override for those packages as well.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/sage-devel/aAesJU1lsVN-O2Q8%40mertle.
