I currently don't have the time to try it out, but I'm pretty sure that meson will not rebuild any cython file if you just update a dependency (that was found via pkg-config) since meson is not watching pc files (or the like) for changes. If the new version is incompatible, then I expect you get just a runtime error. Even in the case where a dependency is updated and a cython file is changed (so meson is run by meson-python with `--reconfigure`), the dependencies are normally cached and so the updated dependency will not be detected (there is an open issue to disable this caching: https://github.com/mesonbuild/meson/issues/6180).
In either case, I would recommend a full rebuild of sagemath after updating any dependencies. On Saturday, February 7, 2026 at 5:27:30 PM UTC+1 Michael Orlitzky wrote: > On 2026-02-06 10:04:16, Nils Bruin wrote: > > As far as I can see, a recompile (or at least a significantly longer > > start-up time) for sage is triggered whenever some packages have been > > upgraded (so a "dnf update" on a fedora system, for instance). I don't > know > > which package updates trigger this. Is it a new python becoming > available? > > It should really just stick to the python it's configured with and only > > change upon reconfiguration. > > The ninja build rules are being generated with implicit dependencies > on the libraries being linked. For example, > > build ... | /usr/lib/libglpk.so.40.3.1 /usr/lib/libgmp.so > LINK_ARGS = -Wl,--as-needed -Wl,--allow-shlib-undefined -shared > -fPIC -Wl,-O1 -Wl,--as-needed -O3 -pipe -mabi=lp64d -march=rv64gc > -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -flto > -Wl,--start-group -lglpk /usr/lib/libgmp.so -Wl,--end-group > > So even though -lglpk is being used to link, the build system has > pre-resolved that and followed the symlink from libglpk.so to > libglpk.so.40.3.1. Unless I am mistaken, whenever libglpk.so.40.3.1 > changes, this target will be rebuilt. > > This bothers me because the library version (40.3.1) exists precisely > to indicate when the ABI/API has changed, and consumers need to > rebuild. On the other hand, we do these triggered rebuilds for an > entire linux distro, and the packages that get library versioning > correct are negligible. In the absence of hand-curated rebuild > information (what we do) rebuilding by default is the least bad > alternative. > > > > It is a problem if people run "automatic" updates on their machines > (which > > is somewhat doable nowadays): then it becomes totally unpredictable > whether > > sage will recompile or not. Really, in that case part of the > post-install > > cleanup should be "run/recompile sage". It looks like dnf can be > configured > > to have "post-transaction-actions" but that's a big ask from users. > > For developers this is harder to avoid, but eventually end users will > be able to install a Sage distro package, and the distro can take care > of this. (The sage-on-gentoo overlay does automatic rebuilds, for > example.) > > > > Perhaps we do need to recommend conda installs in stronger terms, to > > insulate the sage install more from system updates. > > A non-editable install would at least give you the option to run > "sage" and see if it crashes before wasting time on a rebuild. > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sage-devel/c2be7f7e-de80-47ae-bf9f-50ece14b99fbn%40googlegroups.com.
