botan3: Submission, put version 3 into name botan; botan2: Bugfix, Python build, change name to botan2

[essandess]

Description

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS x.y
Xcode x.y / Command Line Tools x.y.z

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL in commit message?
• checked your Portfile with port lint?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?
• checked that the Portfile's most important variants haven't been broken?

[barracuda156]

PowerPC needs this: https://github.com/macos-powerpc/powerpc-ports/blob/722ca35e35d2960c0ab2e1b4ef65fe9f193d9c71/security/botan3/files/0001-cpuid_ppc.cpp-fix-for-macOS.patch
Some older macOS versions (I don’t know threshold, should be safe generally) need this: https://github.com/macos-powerpc/powerpc-ports/blob/722ca35e35d2960c0ab2e1b4ef65fe9f193d9c71/security/botan3/files/0002-getentropy-add-missing-header-for-macOS.patch

[essandess]

Related:

• botan: Update to version 3.5.0.; Bugfix #26033 (comment)
• botan: Bugfix Python build; use Python 3.14; Change name to botan2 #33643

[essandess]

https://github.com/macos-powerpc/powerpc-ports/blob/722ca35e35d2960c0ab2e1b4ef65fe9f193d9c71/security/botan3/files/0002-getentropy-add-missing-header-for-macOS.patch

Added, thank you.

[RJVB]

For completeness' sake: my tested version of the port is here: https://github.com/RJVB/macstrop/blob/master/security/botan3/

Tested on 10.9.5 with GCC13 (with -stdlib=libc++ of course) and MacPorts clang-17 (because earlier versions have doubtful C++20 support). Both require a recent enough libc++ (probably v17+ for the C++20 thing), and in the case of clang, the port's own libc++ (headers) cannot be used on 10.12 and earlier because they preserve the absence of features introduced in later OS versions.

I haven't checked how that situation has evolved in the official ports tree, but it looks like it might be a good idea to add +botan2 variants to ports that currently build against Botan2.

The test suite also completes a LOT faster for Botan2 compared to Botan3, and that's not just because there are fewer tests. I think it may have something to do with the fact that Botan3 dropped all but 1 of the intrinsics selection options and AFAICT even some implementations (like for SSE4.2). In other words, a possibility to build/run against botan2 should be a win-win for older machines.

NB: either remove the native variant, or add the --disable-neon argument to the default configure.args as in my port version.

[RJVB]

On Thursday July 30 2026 06:23:23 Renee Otten wrote: @reneeotten requested changes on this pull request. how do downstream packages know about this change, aren't they still looking for a "botan" executable?

I'm not convinced that driver exec is used by any of the dependent ports, but this is one reason why I suggested not to introduce a `port:botan3` but instead upgrade the existing port:botan after splitting off the port:botan2 "legacy" port. (That and because the same thing has already been done with Botan1)/.

[essandess]

On Thursday July 30 2026 06:23:23 Renee Otten wrote: @reneeotten requested changes on this pull request. how do downstream packages know about this change, aren't they still looking for a "botan" executable?
I'm not convinced that driver exec is used by any of the dependent ports, but this is one reason why I suggested not to introduce a port:botan3 but instead upgrade the existing port:botan after splitting off the port:botan2 "legacy" port. (That and because the same thing has already been done with Botan1)/.

I agree about keeping the name botan rather than botan3. The latest force-push keeps name botan, but I had to keep this in directory security/botan3 until #33643 is merged.

Should we combine #33643 and this PR so that all these changes appear concurrently?

[RJVB]

essandess left a comment (macports/macports-ports#33642) Should we combine #33643 and this PR so that all these changes appear concurrently?

That seems logical, and would certainly make it easier for other to test things.

[essandess]

essandess left a comment (macports/macports-ports#33642) Should we combine #33643 and this PR so that all these changes appear concurrently?
That seems logical, and would certainly make it easier for other to test things.

Latest force-push incorporates #33643 into this PR.