boost178, boost181: backport BOOST_CLANG_VERSION fix for LLVM clang

[chrstphrchvz]

Description

I have not observed a specific error in MacPorts which this fixes, but since MacPorts often uses LLVM clang instead of Apple clang, it seems it would be beneficial to have this fix.

Type(s)

• bugfix

Tested on

Not tested from MacPorts.

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?
• checked your Portfile with port lint --nitpick?
• 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?

[macportsbot]

Notifying maintainers:
@mascguy for port boost178, boost181.
@michaelld for port boost178, boost181.

[michaelld]

@chrstphrchvz are other boostXYZ, with XYZ != 178 or 181, not effected by this issue? For example between 178 and 181 MP has 179 and 180 ... usually the code like this is not that different between versions, hence my wondering

[mascguy]

@chrstphrchvz are other boostXYZ, with XYZ != 178 or 181, not effected by this issue? For example between 178 and 181 MP has 179 and 180 ... usually the code like this is not that different between versions, hence my wondering

Michael, I've pruned our Boost ports considerably, as maintenance was starting to become burdensome.

So now there's only:

• boost171
• boost176
• boost178
• boost181

[mascguy]

Michael, I've pruned our Boost ports considerably, as maintenance was starting to become burdensome.

So now there's only:

• boost171
• boost176
• boost178
• boost181

Eventually we'll add a newer version too - and there's an open enhancement request for that - but there hasn't been the need.

[mascguy]

Michael, I've pruned our Boost ports considerably, as maintenance was starting to become burdensome.

So now there's only:

• boost171
• boost176
• boost178
• boost181

P.s. Originally I had hoped to drop 178 too, but there are a few ports that don't work with 181 yet. (And didn't want to risk any issues by dropping back to 176, in case those ports need newer features in 178.)

[chrstphrchvz]

Currently, this is applicable to boost 1.78 and later, and I do not know if boost 1.84 will include this change. So boost178 and boost181 are the only ports affected.

[michaelld]

@chrstphrchvz thanks for the thorough explanation! I'm clearly out of the loop & playing catch up with the state of ports. I fully support paring down ports where it can be done, so thank you for that work!

[catap]

Shall boostorg/mpl#77 be backported as well?

[kencu]

Shall boostorg/mpl#77 be backported as well?

they haven't accepted that one yet, it seems, and there is a competing idea going here:

#21839

[kencu]

I took it back to the upstream issue to see if we can get the fix that boost will officially integrate:

boostorg/mpl#69 (comment)

[kencu]

boost 181 builds fine on MacPorts with clang-17. I was expecting it to fail, given the above three comments.

boost 176 does fail on MacPorts with clang-17, as we know. Perhaps all we need is the fix in this PR there? Let me try that.