openrct2: builds failing for 10.13 and earlier, with macports-libcxx: cyclic dependency errors

[mascguy (Christopher Nielsen)]

In the interest of providing this port to an expanded set of macOS releases/users - originally it required 10.15 and later - this port was updated to utilize macports-libcxx.

As for the previous 10.15+ requirement, that's related to use of libcxx features only present in 10.15 and later. That makes it a perfect candidate for macports-libcxx, which fills that gap. And thus far, the latter works beautifully, based on its use with other ports.

Of note, it's understood that upstream may be dependent upon newer macOS APIs. So it's not yet clear what the floor is, relative to a minimum macOS version for this port. (At least without modifications/patches.)

Nonetheless, at least in local testing, macOS 10.13 does appear to work properly: Not just for the build, but at runtime as well. Confirmed by running with official Roller Coaster Tycoon 2 game files, purchased from GOG.

However, on our buildbots, builds are failing for 10.13 and earlier. And the errors involve potential cyclic dependencies, during header inclusion/consumption.

Here is one example, for 10.13:

​https://build.macports.org/builders/ports-10.13_x86_64-builder/builds/133693/steps/install-port/logs/stdio

openrct2/work/OpenRCT2-0.3.5.1/src/openrct2/platform/Platform.macOS.mm
While building module 'std' imported from openrct2/work/OpenRCT2-0.3.5.1/src/openrct2/platform/../Diagnostic.h:12:
While building module 'Darwin' imported from /opt/local/include/libcxx/v1/ctype.h:38:
In file included from <module-includes>:74:
In file included from /opt/local/libexec/llvm-9.0/lib/clang/9.0.1/include/tgmath.h:21:
/usr/include/tgmath.h:27:10: fatal error: cyclic dependency in module 'std': std -> Darwin -> std
#include <math.h>
         ^

It's possible that this is a relatively simple issue, perhaps related to compilation arguments. However, more discussion and investigation is needed.

[kencu (Ken)]

Assuming this is related to c++ modules, as it appears to be, this issue has so far been not trivial to work around.

They make the SDK headers in one place use other headers in that place, ignoring your header include paths.

[Christopher Nielsen <mascguy@…>]

In 88f73b160c089ae85f57f275d6d503c957ed2be5/macports-ports (master):

openrct2: use 10.14 as minimum supported macOS release

• While 'macports-libcxx' expanded support to 10.14, C++ modules are problematic on 10.13 and earlier.

See: #64247

[mascguy (Christopher Nielsen)]

Replying to kencu:

Assuming this is related to c++ modules, as it appears to be, this issue has so far been not trivial to work around.

They make the SDK headers in one place use other headers in that place, ignoring your header include paths.

Ken, while I'm still a bit foggy on the interactions, what is driving the behavior? For example, is it rigid header/path inclusion enforced via the toolchain, which can't be overridden? Or...?

Ultimately I'm just trying to understand where the issue is, and whether it would be feasible for us to sidestep it.

[kencu (Ken)]

I have this ticket for you to look through:

​https://trac.macports.org/ticket/59992

There are quite a few rather personal digs in that ticket, but people were understandably having a hard time wrapping their heads around what was going on with modules, so ignore those (I did).

And these two references:

​https://stackoverflow.com/questions/22693950/what-exactly-are-c-modules

​https://www.modernescpp.com/index.php/c-20-modules

and my admission that my understanding of all this is also not deep and fulfilling...