remove boost_cropped spkg, add boost to prereqs

[dimpase]

boost is available on all the supported platforms, and maintaining the spkg thus makes no sense any more. So e.g #34748 can be closed

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview.

⌛ Dependencies

[github-actions]

Documentation preview for this PR (built with commit 5373b22; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[tobiasdiez]

CI fails but the error looks a bit cryptic to me.

[dimpase]

CI fails but the error looks a bit cryptic to me.

they all seem to have quite old boost. I'm trying now to go for the smallest.

[dimpase]

"Prepare source distributions and wheels" CI runs fail as they use a stale ./configure from a previous release; "standard / linux (ubuntu-focal, standard)" fails as it cannot build gmp;

so it looks as if it's good enough.

[dimpase]

I merged #40708 here to unblock docker image building

[tobiasdiez]

There are some CI errors.

[tobiasdiez]

The failures of "release_dist" and opensuse seem to be relevant:

Checking whether SageMath should install SPKG zeromq...
checking whether any of gcc is installed as or will be installed as SPKG... no
checking for zmq.h... no
real_configure: WARNING: no valid ZMQ installation was found
real_configure: no suitable system package found for SPKG zeromq

(in the dist workflow)

(ignore the wheel failures, this part is disabled in #40709)

[dimpase]

OpenSuse 15 is an outlier, in the sense it only has Boost 1.66. So I made this version the lower bound - not sure actually if the thing will build. If not, we would have to install Boost from source, or from a community repo (what's the syntax?), for OpenSuse 15.

[tobiasdiez]

Do you have an idea what's happening in the almalinux and debian-bookworm runs? Previously they took about 2.5h, but now they timeout after 6h.

[dimpase]

Do you have an idea what's happening in the almalinux and debian-bookworm runs? Previously they took about 2.5h, but now they timeout after 6h.

not sure which runs you are referring to - can you point at them?

[tobiasdiez]

https://github.com/sagemath/sage/actions/runs/17531188671/job/49788358974?pr=40689
and
https://github.com/sagemath/sage/actions/runs/17531188671/job/49788358955?pr=40689

[dimpase]

https://github.com/sagemath/sage/actions/runs/17531188671/job/49788358974?pr=40689 and https://github.com/sagemath/sage/actions/runs/17531188671/job/49788358955?pr=40689

https://github.com/sagemath/sage/actions/runs/17531188671/job/49788358974?pr=40689

is just a dog-slow host (30 minutes (and 60 minutes of wall-clock time) to build pari or ecm?), where, due to the deficiency of the platform most everything has to be built from source.

Unless we use something like a pre-built docker container with most deps already there, it's basically hopeless to expect this to work.

[tobiasdiez]

Okay, it was also working well before the last merge commit. So let's hope it was only a temporary GH issue.

[vbraun]

I have no idea how to install boost on macos, and I wager that lots of users don't know either.

If you need to manually compile boost first then we might just as well give up on having an end-user installable version and decide that you can only build Sage on top of macports or whatever macos package manager we pick. Which is an argument that you can make, but please not under the guise of "removing boost" but lets have an honest discussion about it.

[dimpase]

I have no idea how to install boost on macos,

@vbraun - did you have a look at the PRs branch? Because it does explain this, briefly.
You need a C++ compiler (clang from XCode)
and 5 to 10 minutes.

and I wager that lots of users don't know either.

There is very little demand in installing Sage on naked macOS, as far as I know.

Besides, if you are a super-duper hacker who would venture into building Sage on macOS without Homebrew or Conda, chances are you might already have Boost installed in some other way (e.g. via vcpkg) or you are ready to build it from source (once every few years), which isn't even close to the difficulty and the sheer amount of time needed for building Sage on a naked macOS.

Anyhow, installing boost needs only C++ compiler, nothing else, if you follow their default recommendations, to use b2.
On my old x86_64 powerbook installing full latest boost using this method took 12 minutes of wall-clock time.

If you like I can add this to the instructions in the PR text.

[dimpase]

I took the liberty to remove the "needs work" label, as it really is not the case.

[vbraun]

I looked at the patch, it has a link to a "boost installer". I opened the link and only saw a wall of text about compiling on various operating systems, and no installer. Immediately closed the browser tab, fsck that!

[tobiasdiez]

I don't quite get the problem. The docs for prereq already mention that you may have to use homebrew/macports or a manual install of those dependencies:

On macOS, suitable versions of most of these tools are provided
by the Xcode Command Line Tools. ... The remaining are provided by either one of macOS's
"missing package managers", such as Homebrew, or as standalone
tools.

And boost is available from both homebrew and macports, or not?

Moreover, at least for sage-the-lib, boost is optional - so if it's also optional for the dependencies, then you don't have to install it at all.

[dimpase]

I looked at the patch, it has a link to a "boost installer". I opened the link and only saw a wall of text about compiling on various operating systems, and no installer. Immediately closed the browser tab, fsck that!

I am slightly worried that @vbraun 's GH account has been hijacked by script kiddies, who can't read texts longer than 180 chars without a 6-pack of Red Bull... :-)

But, seriously, if we start looking carefully at https://doc.sagemath.org/html/en/reference/spkg/_prereq.html we will see it contains outright lies: the need for a C compiler is not even mentioned, and there are no instructions on installing XCode (and the latter in various years were rather non-straightforward, who knows, perhaps Apple starts again to ask for an account on their "shop" or whatever).

Thus if I am to add more info on Boost, I will also need to fix this.

So, @vbraun - how does one install XCode on a new machine anno 2025? (OK, I also can skip this fun part). Because, you know, https://developer.apple.com/xcode/ is a wall of crap, not even text. There is a small tap "Download" in the top right corner, easy to overlook. And this doesn't let you go far on a non-Mac, all I can see is "Mac App Store preview", "Open the Mac App Store to buy and download apps.".
This just screams user-friendliness :-)
Homebrew mentions in its installation guide that one needs XCode command line tools, located at
https://developer.apple.com/download/all/ (the link brings one to "Sign in to Apple Developer" page :-))
or XCode (linked to an iTunes page). That's all really a rabbit hole down in an Apple orchard if you ask me - compared to this Boost pages are exemplary

[vbraun]

I've added passing the boost path from ./configure down to meson in #41030: 27b54da

[dimpase]

The native.ini mechanism is just meson's preferred way of adding system-dependent configuration, its entirely analogous to ./configure --with-foo=... just that meson prefers it in a file instead of as commandline variables. And we already have a dynamically generated meson-python-native-file.ini to configure the python binary, this is really standard stuff.

And I have already read the meson docs, all you need is to declare boost as

boost = declare_dependency(
  dependencies: [
    cc.find_library('boost_system', dirs: ['/Users/vbraun/boost-install/lib'])
  ],
  include_directories: include_directories('/Users/vbraun/boost-install/include'),
)

the only thing thats lacking is a mechanism to patch the configure-ed path into meson.

it seems that then you must use .ini files - although meson docs are pretty silent on this.

Also after boost=declare_dependency(... one still needs boost=dependency('boost')
as far as I know.

[dimpase]

I still don't understand why it is so complicated to pass the --with-boost down to brial, I've followed the analogous path that we use for other configure variables in #41030 and I only had to add a single line of m4 code

because the old style code using env vars was needed for setuptools to get info on headers and libs. Env vars are not needed for meson.

[vbraun]

Also after boost=declare_dependency(... one still needs boost=dependency('boost') as far as I know.

Both the declare_dependency and dependency factory functions return a dependency object, so if you do both then the latter overwrites the former in the namespace.

A third way (and what I ended up using in #41030) is a boost_root property that meson's built-in boost support looks at.

Env vars are not needed for meson.

OK good, but I'd still very much would like to avoid a) the even more unfortunately named spkg-install.in.in and b) a mix of two different ways of passing down the prefix without any clear guidance about which one is the recommended one

[dimpase]

@vbraun - needs review (and merge 😃 )