[MacPorts] #67164: gcc12 @12.2.0_2: gcc is baking in a fragile specific sdk because regex test is not mstching SDKs without a decimal point

[MacPorts]

#67164: gcc12 @12.2.0_2: gcc is baking in a fragile specific sdk because regex test
is not mstching SDKs without a decimal point
----------------------+--------------------
  Reporter:  jsalort  |      Owner:  (none)
      Type:  defect   |     Status:  new
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:  2.8.1
Resolution:           |   Keywords:
      Port:  gcc12    |
----------------------+--------------------

Comment (by cjones051073):

 The regex when added was never intended to force `MacOSX.sdk`, it has
 never ever done that.

 It was *specifically* only intended to deal with the fact that when
 macOS11 was released, in the early days of the SDKs they would change
 rapidly between minor versions. So 11.0 and 11.1 had different SDKs.
 MacPorts never expected this and it caused issues, so this regex was
 added. This happened because of how Apple changed the meaning of their OS
 versions. They went from 10.X being the major versions, with 10.X.n being
 the minor revision, to just X for the major and X.n for the minor.

 We could think about just forcing the use of the completely version less
 SDk, but this is a change different to what we have done before. I would
 want to think through what side effects that could have.

 Also note, even this will *never* be a complete fix, it will still be
 possible for a user to have a different SDK path choice to whatever the
 binary installs are built with. As say the build bots built gcc using the
 Xcode SDK at a specific location, a user could still have only the CLT
 installed, or Xcode at a custom location. So the issue is still, at least
 in theory still there.

 The correct solution here, which is what I always recommend, is for the
 user to *not* rely of the default SDK built into gcc, but to tell it what
 to use. The mechanisms to do this have been available for some time, and
 GCC (intentionally) uses the exact same methods as Clang (which
 incidentally has more or less the same need). The ways to do it are

 1. Run through scrub

 {{{
 > xcrun g++-mp-12 ...
 }}}

 scrub corrects the correct runtime environment, including info on the SDK,
 which gcc then uses.

 2. Set SDKROOT environment var

 {{{
 SDKROOT=/path/to/SDK g++-mp-12 ...
 }}}

 or if you prefer

 {{{
 SDKROOT=/path/to/SDK
 g++-mp-12 ...
 }}}

 In both the above, gcc respects your SDKROOT setting and will use whatever
 it points to.

 I personally use the second, and actually have

 {{{
 export SDKROOT=`xcrun --show-sdk-path`
 }}}

 in my shell profile, so whenever I start a SHELL this env var gets
 automatically set to whatever my current SDK choice happens to be.

 Note the above is also exactly what you should do with clang, to inform it
 what SDK to use. Macports clang builds in particular rely on this as they,
 like GCC< cannot assume any specific SDK location that the user will have
 installed.

 For now I am inclined not to change anything here.

-- 
Ticket URL: <https://trac.macports.org/ticket/67164#comment:17>
MacPorts <https://www.macports.org/>
Ports system for macOS