bump(main/boost): 1.90.0

[robertkirkman]

• fix-aligned-alloc-detection.patch fixes a preprocessor conditional mistake introduced in boostorg/asio@8b80ad7

• Revision-bump all reverse dependencies in the packages folder

[robertkirkman]

@TomJo2000 I tried to remove this variable _VERSION as I know you like, but unfortunately, it didn't work.

If you would prefer this variable to be removed, do you know if it's possible?

[TomJo2000]

Yeah if there's an epoch that gets trickier.
I think asciinema has that scenario though.

In that package we use the bash built-in $_ variable as a temp variable.

termux-packages/packages/asciinema/build.sh

Lines 5 to 7 in 7f8d572

	TERMUX_PKG_VERSION="1:3.0.1"
	: "${TERMUX_PKG_VERSION:2}" # We need to remove both the epoch and the '~' from the version
	TERMUX_PKG_SRCURL=https://github.com/asciinema/asciinema/archive/refs/tags/v${_//\~/-}.tar.gz

This may not be ideal either.

[robertkirkman]

If you would like, I'll use that, but to me it looks like a less-readable variant of the same thing.

Is your goal for "no unique global variables" based around a goal of improved readability, or is it based around a goal that needs to fulfill certain technical (programmatically testable) requirements?

Note that currently, all packages are built in individual subshells, so that's why global variables don't currently pollute other packages in a programmatically testable way.

[TomJo2000]

Yeah the solution from asciinema ain't great either.
I just knew it had this scenario.

The main reason I wanna get rid of as many global helper variables as feasible is uniformity.
Mainly for using builds as a reference when submitting new packages.
The less bespoke workarounds are in a build the easier it is for a contributor or maintainer to adapt it to fit a new purpose.
It's not really a strong reason, I just think we shouldn't be throwing around global helper variables when the contribution guidelines say to use parameter expansion when practical.

Global scope variables must be defined in termux_step_pre_configure() function unless they are part of package metadata.

https://github.com/termux/termux-packages/wiki/Coding-guideline#build-script-buildsh

[robertkirkman]

When a new package is submitted, it won't have an epoch bump, so packages with epoch bumps aren't ideal for copying to form new packages.

[thunder-coding]

Earlier we have had problems with building all of boost dependencies in one go. Rather do 4-5 separate PRs to avoid any automagic dependency problems

[robertkirkman]

Earlier we have had problems with building all of boost dependencies in one go.

oh, I remember now that the problem is that it takes more than 6 hours to build them all and runs out of time. Last time I did 2 PRs and that worked in under 6 hours for each PR.

automagic dependency problems

Could you explain in a little more detail?

[thunder-coding]

automagic dependency problems

Could you explain in a little more detail?

Some times packages autodetect libraries/binaries from PATH and try to build with that feature enabled. See for example in past we have had to deal with:

f3efe58
3449e95
75d4393

(just some of the commits I searched up with git log --grep, pretty sure we have had more of them)

[robertkirkman]

I see, in this case I don't expect that for two reasons:

• When I see those, I fix them, as xtkoba did, though I haven't been referring to them as "automagic" which might lead to some differences in commit message phrasing. Fixing them makes Termux more stable, so if you see any, let me know. Since I have been fixing them when I find them, there are currently a little bit fewer of them in Termux than there might have been when you last checked, particularly since the time of those commits you linked
• I revision-bumped all reverse dependencies of boost 1.89 in exactly the same PR groups as now, so if any unmarked dependencies have been linked, they have been since that time and haven't been noticed yet bump(main/boost): 1.89.0 #25882