Xcode part misdetects the build arch

[barracuda156]

(cd uimac; \
      LIB_SUFFIX=$(ocaml -e 'if Sys.ocaml_release.major > 5 || Sys.ocaml_release.major = 5 && Sys.ocaml_release.minor >= 1 then print_string "nat"' 2> /dev/null); \
      printf "MARKETING_VERSION = 2.53.5\nOCAMLLIBDIR = /opt/local/lib/ocaml\nOCAMLLIB_UNIX = -lunix${LIB_SUFFIX}\nOCAMLLIB_STR = -lcamlstr${LIB_SUFFIX}" > ExternalSettings.xcconfig)
(cd uimac; xcodebuild -arch Power Macintosh   SYMROOT=build)
unknown option: -arch
Usage: xcodebuild [-project <projectname>] [-activetarget] [-alltargets] [-target <targetname>]... [-parallelizeTargets] [-activeconfiguration] [-configuration <configurationname>] [-sdk <sdkfullpath>|<sdkname>] [<buildsetting>=<value>]... [<buildaction>]...
       xcodebuild [-version [-sdk <sdkfullpath>|<sdkname>]]
       xcodebuild [-showsdks]
       xcodebuild [-find <binary>] [-sdk <sdkfullpath>|<sdkname>]
       xcodebuild [-list]
make[1]: *** [macexecutable] Error 1

Looks like it uses uname -m or its equivalent, which returns Power Macintosh. This is incorrect for detecting the arch; instead, standard Xcode arguments can be used. -arch flag takes the arch of the build, not the cpu family of the machine (which is irrelevant, since it may not be a valid arch flag at all, like in this case, or may differ from build arch).

[tleedjarv]

Yes, there is uname -m in Makefile.OCaml.

Would you be able to propose a PR to fix this? I am not familiar with Macs or Xcode.

[gdt]

@barracuda156 Please give the requested details for a bug report: unison version (and for something like this, please make that "today's git master" even though latest release and up-to-date master are likely the same), hardware type, os version, xcode version. mac is quite complicated and there seem to have been a lot of incompatible changes and deprecations over the years. I am not sure we have a clear statement of what we might consider in scope; the default assumption is "systems receiving ongoing maintenance from the OS provider". But, if something can be done better in a way which does no harm, I am open to reviewing a PR.

It is also perhaps useful to look at the POSIX requirements for uname. A number of systems also implement -p which NetBSD documents to return the machine processor architecture name. However, Apple seems to choose to return i386 for systems that are operating as x86_64.

All that said, use of uname -m is sort of a bug, although it's also buggy of xcode not to be set up to take uname output to do what people want.

I think it comes down to finding an expression to tell xcode to build for the build host's CPU family, but that can't be uname -p because of Apple's buggy use of i386 as the answer.

It could be that we run up against Apple bugs once understood, in which case I'll ask you to file them with Apple. They don't get a pass just because people expect them to be intractable :-)