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

[gdt]

I didn't set the feedback label, but it was clear that further info is needed. As "power mac" is mentioned, and it has been many many years since any apple OS has been in supported status for a ppc system, I'm going to close this as applying to unsupported systems.

That said, a PR that rationalizes and improves mac/xcode support is welcome. I'm just saying that a bug about ancient releases isn't going to continue to cause cognitive load when reviewing the tracker.

[barracuda156]

@gdt Sorry, I was away from my hardware for almost a month, so could not address anything in the interim.

This is not a specifically PowerPC issue though, since macOS supports building for a an arch different from the physical cpu, and that includes building for i386 on x86_64, not only building for ppc. Current code will get this wrong either, since uname has no way to figure out the arch of the build.

[gdt]

Please feel free to open a new bug that can argue that building on a supported model (x86_64 or aarch64) fails, and more importantly a PR to fix it. Neither of us working on unison is dealing with xcode. (I do use unison on mac, but I build it under pkgsrc treating the system as a slightly odd posix, vs native mac.)

[barracuda156]

I do use unison on mac, but I build it under pkgsrc treating the system as a slightly odd posix, vs native mac.

@gdt I will check what pkgsrc does. Maybe the portfile in MacPorts can be adjusted accordingly to avoid relying on Xcode in any way (which is what I would certainly prefer myself).

[gdt]

pkgsrc just runs gmake. But I pay zero attention to the mac gui.

also note that we build for mac in CI and I think that builds the mac gui. Note "I think"; I don't pay attention to that.

[barracuda156]

pkgsrc just runs gmake. But I pay zero attention to the mac gui.

also note that we build for mac in CI and I think that builds the mac gui. Note "I think"; I don't pay attention to that.

Looking at the portfile now, I do not think Xcode is invoked from MacPorts side on the OS version I used. Perhaps it is called from the source code itself, in which case pkgsrc will use it either (Xcode does not depend on its IDE, it uses xcodebuild from CLI). Also, on Darwin < 17 MacPorts uses GTK GUI backend, not Cocoa.

Anyway, I will take a look at this again a bit later to see if this can be fixed in a neat way.