[MacPorts] #54773: port:libgcc/port:gcc7: proposed modifications, efficiency + libc++ support

[MacPorts]

#54773: port:libgcc/port:gcc7: proposed modifications, efficiency + libc++ support
--------------------------+----------------------
  Reporter:  RJVB         |      Owner:
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:  haspatch
      Port:  gcc7 libgcc  |
--------------------------+----------------------

Comment (by RJVB):

 Replying to [comment:8 jeremyhu]:
 > > What I don't get is why it doesn't simply invoke clang.
 >
 > Because that's not what it's doing in as/driver.c.  We can have it do
 whatever we want.  I don't think searching $PATH for clang is good though
 because then we get nondeterministic behavior.  We should have it envoke a
 fully qualified path or fail.

 This should be discussed on a dedicated ticket, but I don't think the non-
 deterministic behaviour is a problem here. Even with a full path the
 behaviour remains nondeterministic, or if you want, without specifying a
 path `as -q` behaves just as deterministically as with ... user-
 deterministic. Meaning it's the user who decides what $prefix/bin/clang
 points to. I think that's fine in this case. And yes, I realise that
 `/usr/bin/as -q` invokes /usr/bin/clang but that's a bit different in that
 it can be expected to invoke the system clang specifically.

 Making this an issue would basically mean that cmake, gmake and all ports
 shipping an IDE or software that can invoke a compiler would also have to
 provide variants that determines the default clang-mp. Instead we let
 those invoke their default compiler as `clang` or even `cc` and be done
 with it.

 It would be somewhat different if `as` itself was being maintained, but
 from what I see it is basically an *old* GNU `as` that hasn't changed
 (much) since a long time. But even in that case `as` would be a different
 beast than clang.

 On a related note, would making cctools depend on llvm_select make this
 any "cleaner"? I think it's the closest thing we have to a generic
 `port:clang` and at least it would give an indication that it might
 require files installed by `port select`.
 >
 > The purpose of port:libgcc is't about depending on specific compiler
 versions or not.  It's about making sure that all the gcc compilers use
 the same (newest) runtime libraries to avoid pulling multiple copies into
 a single process.

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