[MacPorts] #64532: graphite2 fails to build for ppc on 10.6.8 (Rosetta): unrecognized command line option '-mfpmath=sse'

[MacPorts]

#64532: graphite2 fails to build for ppc on 10.6.8 (Rosetta): unrecognized command
line option '-mfpmath=sse'
---------------------------+-------------------------------------------
  Reporter:  barracuda156  |      Owner:  (none)
      Type:  defect        |     Status:  new
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.7.1
Resolution:                |   Keywords:  powerpc, snowleopard, rosetta
      Port:  graphite2     |
---------------------------+-------------------------------------------

Comment (by ryandesign):

 Upstream did
 [https://github.com/silnrsi/graphite/commit/4f78a29ef31572f1360ae457ea0b9163b28eb039
 accept that patch] so they might accept improvements to it. However I'm
 not sure that any changes are needed in graphite2; the changes may be
 needed in the cmake portgroup.

 Seems like during your build `CMAKE_SYSTEM_PROCESSOR` had the value of the
 build machine's processor, even though you were wanting to cross-compile
 for PowerPC on an Intel machine. According to
 [https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PROCESSOR.html
 the documentation], `CMAKE_SYSTEM_PROCESSOR` should have the correct value
 for cross-compiling if we use a `CMAKE_TOOLCHAIN_FILE`, but as far as I
 know nothing in MacPorts makes any attempt to do that. If you want to
 improve cross-compilation support for cmake projects in MacPorts, that's
 probably what to look at. I would guess that any successful use of a
 toolchain file would also require doing separate builds for separate
 architectures, which would mean using the muniversal portgroup.

 Attempting to make the cmake portgroup always include the muniversal
 portgroup would probably have adverse consequences for at least a handful
 of ports that already do successful universal builds, so this might be the
 kind of fix that would have to be introduced in a new version of cmake
 portgroup (we already have 1.0 and 1.1 so maybe 1.2) and ports would opt
 into that new version over time.

 I'm not sure how common it is for cmake projects to make decisions based
 on `CMAKE_SYSTEM_PROCESSOR`. If it's uncommon, maybe making changes in
 individual affected ports like graphite2 is better than trying to craft a
 general solution that can go in the portgroup.

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