libomp: use newer python for new systems

[i0ntempest]

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?

[macportsbot]

Notifying maintainers:
@eborisch for port libomp.

[i0ntempest]

Use python 3.10 for systems before 10.9 which does not have complete C++11 support (which is what everyone and ChatGPT says). If this version is wrong let me know.

[jmroot]

We don't really want to be stuck using 3.10 on the older systems either. It would be better to solve the bootstrap problem.

[kencu]

we looked at this a few months ago too -- it's to be noted that libomp is actually not a build or run dep for any clang version, it's just been added for "convenience" basically, to facilitate OMP use.

So I believe it could be removed from the clang builds, basically, and the libomp dep added later on in some as-yet-not-created libomp portgroup perhaps or managed in some other way, rather than making it a runtime clang dep.

[eborisch]

It looks like there is a compiler.openmp_version (in portconfigure.tcl) already that can be set to enforce a libomp dependency when needed.

I'm fine with removing libomp as a dependency of clang.

It could also be built as part of clang -- the downsides being that multiple versions of libomp (one per clang) would be installed (minor issue), but also any program that relies on libomp would then need to have clang installed as a runtime dependency (likely a larger issue).