[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 barracuda156):

 Replying to [comment:4 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.

 Is there any reason to use `CMAKE_SYSTEM_PROCESSOR` and not
 `CMAKE_OSX_ARCHITECTURES` there? With the latter everything works
 correctly on 10.6.8 Rosetta.

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