This does not work on M1 Macs

[alexanderrtaylor]

Just a heads up (this is 100% not on this repository but there is not a better place to warn anyone) this is unable to build on M1 macs because they are considered arm machines but there is not a mac arm build on the perforce download site

Feel free to close this since it is not your issue but I wanted it recorded somewhere that M1 macs are unable to build this because the G++ libraries that they use are for arm machines but that is not compatible with the x86/x64 intel C helper files from perforce.

Thanks so much for building this!

---

Unfortunately even with a docker container running in the M1 there is not an arm linux release which would indicate they have no desire to run on ARM CPUs. So I had to swap to another machine.

[twarit-waikar]

@alexanderrtaylor Thanks for the heads up!

Indeed it looks like Helix Core C/C++ is not currently supported for ARM (as of their 2021.2 API version). I'd like to keep this issue open and probably on the back-burner till we get some communication on whether they plan on supporting ARM.

I don't think there is anything on this repository that can't be ported to ARM, except the Helix Core C++ API, so once we do get confirmation, supporting ARM would be easy.

For now, the workaround is as you have already done i.e. shift to a different machine or run p4-fusion in Rosetta emulation mode (likely to be painfully slow)

[twarit-waikar]

It looks like there is Apple Silicon support in the Helix Core C++ API 2021.2 from the release notes

Major new functionality in 2021.2

	#2142991 (Job #107010) *
	    P4API builds for Apple Silicon are now supported using
	    OS=MACOSX, OSVER=1101 (or greater) and OSPLAT=ARM64.

We should be able to use that

[Strum355]

We've tested this out in our nix derivation and it compiles+links successfully. Tried a basic clone with ./result/bin/p4-fusion --path //go/... --user admin --src ~/code/clones/ --networkThreads 64 --printBatch 10 --port perforce.test.com:1666 --lookAhead 2000 --retries 10 --refresh 100 --client user which succeeded without any other errors. I dont know if theres some specific code-paths that should be tested that may be missed by this basic command.

This also includes a bump of openssl to 1.1.x (1.0.2 is marked insecure anyways)

$ file ./result/bin/p4-fusion
./result/bin/p4-fusion: Mach-O 64-bit executable arm64

[twaritwaikar]

@Strum355 That looks fantastic!

I wasn't aware that porting it to arm64 for macOS would not require any big changes in the source code itself.

I have been running some experiments to try to build a fat binary (x64+arm64) for macOS but I was hitting some CMake roadblocks with stuff like not being able to detect if CMake is running on a arm64 device from within the scripts. However, building a arm64 binaries and a x64 binaries separately seems possible / doable in CMake.

Creating two different binaries, one for x64 and arm64 on macOS, and lipo-ing them together on macOS might be the best alternative for us in that case, rather than trying to use CMake to build a fat binary in a single CMake invocation.

Looked like you were able to get it running fine using nix (I do need to read more on this tool). However, I am not sure how you were able link to the Helix Core C++ API. The release notes mention that we need some special macros while using their headers (as I posted above), which we have not been doing in the master branch as of now. Do you have info on how that was accomplished?

Also, do you recommend us to maintain a first party macOS arm64 port of this tool alongside your porting work?

[Strum355]

However, building a arm64 binaries and a x64 binaries separately seems possible / doable in CMake.

Thats the approach Id be going with as well (mostly because I dont know anything about cmake to do otherwise lol)

Do you have info on how that was accomplished?

Absolutely nothing different compared to before 🤷 Can see my changes here sourcegraph/sourcegraph@93c19a5 (#44588) only involve removing some libre-ssl stubbing we had to do, and changes the libressl dependency out for openssl 1.1.1

Also, do you recommend us to maintain a first party macOS arm64 port of this tool alongside your porting work?

There was no additional work required for us to support macOS arm64 besides fetching the arm64 helix-core API (when building with the newer one), or compiling+linking using an x86_64 clang13 running on rosetta to build an x86_64 p4-fusion binary (probably nonsensical code to you, but all it took was having existing nix code for x86_64 macOS build and then pointing the arm64 build target at that here). So as far as your question is concerned, Im not sure what would actually be involved, given its been no problem so far. We only created the nix derivation as people were having issues building it locally, this gives them a (almost quite literally) one command way to build it without having to deal with openssl/other implicit system dependency versioning issues that are pretty notorious in the C++ world :P

[twaritwaikar]

If it did not require any code changes while building p4-fusion through nix for M1 chips then likely we won't need to as well like you said.

I don't believe there would be x64 platform dependent code in this repository, although I should confirm that in the dependencies.

Your Perforce clone test on M1 should cover the most important code path afterall.

[peterguy]

Check out https://docs.sourcegraph.com/dev/background-information/build_p4_fusion for instructions on building p4-fusion on various platforms.