[MacPorts] #67825: Possible to add CI and/or buildbots with GCC (on Intel)?

[MacPorts]

#67825: Possible to add CI and/or buildbots with GCC (on Intel)?
----------------------------+---------------------
  Reporter:  barracuda156   |      Owner:  admin@…
      Type:  defect         |     Status:  new
  Priority:  Normal         |  Milestone:
 Component:  buildbot/mpbb  |    Version:  2.8.1
Resolution:                 |   Keywords:
      Port:                 |
----------------------------+---------------------

Comment (by ryandesign):

 If we wanted to provide a gcc CI worker, what's probably needed is a way
 to identify those ports that it should build, so that it can skip building
 those it doesn't need to build. Those it doesn't need to build would
 include those ports where a gcc compiler is already selected by default
 and those ports that declare they are incompatible with gcc via blacklist.
 The `port` command line may not provide a way to make these determinations
 but there may be a way to do it with the port API, and a Tcl script could
 be written to do it, along the lines of the
 [https://github.com/macports/mpbb/tree/master/tools existing Tcl scripts
 used by the buildbot].


 Replying to [comment:3 barracuda156]:
 > On 10.6.8 x86_64 setting cxx lib to `libstdc++`, blacklisting clangs (or
 otherwise overcoming Macports forcing those on case-by-case basis) and
 using only GCC works fine.

 Yes if you build all ports that way that could work, for those ports that
 are compatible with gcc. But on your hypothetical gcc CI worker, if we set
 `cxx_stdlib` to libstdc++, that means it can't use any of our prebuilt
 binaries that were built for libc++. MacPorts won't use any binaries if
 the MacPorts installation's `cxx_stdlib` setting doesn't match that of the
 collection of archives, not even for those ports that don't use C++.
 (MacPorts doesn't keep track of which ports use C++.) That means the CI
 worker would have to build every port's dependencies from source as well.
 That is likely to run up against the six hour per-run limit imposed by
 GitHub Actions. So we either keep `cxx_stdlib` set to libc++ and see how
 well g++ copes with libc++, or we have to set up a gcc buildbot worker too
 to provide libstdc++ binaries, and devise a way to store those separately
 from the libc++ binaries that go to users. This is a lot of effort to go
 to to verify a configuration (gcc on modern macOS) that nobody really
 needs. And even if we provide such binaries, they would probably not go
 through our CDN and would be served directly from the buildbot web server,
 using up more of its limited bandwidth.

 I'm also still just not sure how useful this will be. I imagine two
 classes of software: 1. Software written to be cross-platform and probably
 tested most often with gcc on Linux which (if it builds with clang on
 macOS) has a good chance of building with gcc on macOS too, and 2.
 Software written specifically for macOS, probably tested only with clang
 on macOS, which might fail with gcc but who cares because everybody uses
 clang (acknowledging, again, that PowerPC users care since they don't have
 clang available).

 It feels to me like this (verifying that everything builds with gcc) is
 not our problem to solve. [https://xkcd.com/386/ Something will always be
 broken somewhere] and it's not really MacPorts' mission to fix all
 software everywhere in all build modes. I suggest we focus on fixing ports
 in the standard build configurations. There's more than enough work to
 keep everyone busy fixing implicit function declarations, implicit int
 problems, and the other usual host of problems people report when building
 with the default compiler.

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