Support osx-arm64

[longfin]

This PR adds builds for Apple Silicon (a.k.a. M1/M2) to GitHub Releases and NPM.

I'm not sure this is all that needs to be changed due to a lack of context. so please let me know if there's something else that should be considered.

[dahlia]

The built binary actually does not work on Apple silicon Macs:

$ 7z x dist-bin.zip
$ tar xvfJ planet-0.43.0-dev.20221001102841-osx-arm64.tar.xz 
./Libplanet.Extensions.Cocona.pdb
./Libplanet.Net.pdb
./Libplanet.Net.xml
./Libplanet.RocksDBStore.pdb
./Libplanet.Stun.pdb
./Libplanet.pdb
./Libplanet.xml
./libgflags.2.2.dylib
./liblz4.1.dylib
./librocksdb.dylib
./libsnappy.1.dylib
./libzstd.1.dylib
./planet
./planet.pdb
$ file *.dylib planet
libgflags.2.2.dylib: Mach-O 64-bit dynamically linked shared library arm64
liblz4.1.dylib:      Mach-O 64-bit dynamically linked shared library arm64
librocksdb.dylib:    Mach-O 64-bit dynamically linked shared library arm64
libsnappy.1.dylib:   Mach-O 64-bit dynamically linked shared library arm64
libzstd.1.dylib:     Mach-O 64-bit dynamically linked shared library arm64
planet:              Mach-O 64-bit executable arm64
$ ./planet 
Killed: 9

It's the exactly same issue that made me to give up the previous attempt…

See also: https://github.com/planetarium/libplanet/issues/2280#issuecomment-1238870064

[longfin]

I succeed to run an executable built from CI with an adhoc code signing.

bash-3.2$ ./planet
Killed: 9

longfin@longfinui-MacBookAir osx-arm64 % codesign -s - -f planet
longfin@longfinui-MacBookAir osx-arm64 % ./planet
objc[41846]: Class PlaceholderObject is implemented in both /Users/longfin/Downloads/osx-arm64/planet (0x1017393f0) and /Users/longfin/Downloads/osx-arm64/libSystem.Native.dylib (0x122140600). One of the two will be used. Which one is undefined.
Usage: planet [command]

planet

Commands:
  apv
  key
  mpt
  store
  stats

Options:
  -h, --help    Show help message
  --version     Show version

I think that Gatekeeper may disturb running... (idk why it's okay on x86-64 binary, but I guess it may be related to Rosseta2 🤔 )

Anyway, we need an integration for codesigning. I'll work on that when available.

[longfin]

• After macOS 11 on Apple Silicon(arm64), Apple seems to require a codesign more strictly.
• Since Adhoc signing is only valid in the environment of the user who signed it, it cannot be used for CI.
• Some package managers (e.g., Homebrew, dotnet tools) seemed to be prepared for that requirement through Adhoc code signing. (1, 2)
  • so If planet is to be installed only through such channels, we can omit code signing.
  • In that case, our downloader(i.e., download.mjs) also should be adjusted.
• On the other hand, in order to fundamentally eliminate concerns, it is also a possible option for someone in the project to represent and register for the Apple Developer Program and feed to CI.
  • However, who is appropriate to represent this needs to be discussed and may take time.

Unless otherwise noted, it seems like a viable option right away, so I'm working towards adding ad hoc signing to the downloader.

@planetarium/libplanet Any ideas?

[dahlia]

@longfin IMHO, it would be the quickest and the most approachable at present to make download.mjs to ad-hoc sign it immediately after downloading the executable on macOS.

[longfin]

Added adhoc signing on https://github.com/planetarium/libplanet/pull/2365/commits/670f8f30b704361cf145eede41dcb8d786d5fbf1.

PTAL 🙏 @dahlia (and other Apple Silicon users)

[longfin]

Oh, we almost forgot about docs. Could you adjust the following part from Libplanet.Tools/README.md? It would be shown on docs.libplanet.io as well.

Added https://github.com/planetarium/libplanet/pull/2365/commits/c840c986168bdda2c4d9b140c8514b253bae752e, PTAL @dahlia 🙏

[pull-request-quantifier-deprecated[bot]]

This PR has 52 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

---

Quantification details

Label      : Small
Size       : +39 -13
Percentile : 20.8%

Total files changed: 6

Change summary by file extension:
.sh : +1 -1
.md : +4 -2
.csproj : +1 -6
.mjs : +32 -3
.json : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean:

• Fast and predictable releases to production:
  • Optimal size changes are more likely to be reviewed faster with fewer iterations.
  • Similarity in low PR complexity drives similar review times.
• Review quality is likely higher as complexity is lower:
  • Bugs are more likely to be detected.
  • Code inconsistencies are more likely to be detected.
• Knowledge sharing is improved within the participants:
  • Small portions can be assimilated better.
• Better engineering practices are exercised:
  • Solving big problems by dividing them in well contained, smaller problems.
  • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

• Use the PullRequestQuantifier to quantify your PR accurately
  • Create a context profile for your repo using the context generator
  • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
  • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
  • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
• Change your engineering behaviors
  • For PRs that fall outside of the desired spectrum, review the details and check if:
    • Your PR could be split in smaller, self-contained PRs instead
    • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

• One line was added: +1 -0
• One line was deleted: +0 -1
• One line was modified: +1 -1 (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion)
• Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

---

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.

[greymistcube]

@dahlia @longfin Eh... this breaks linux-mono-build (not tests). Can you take another look?

[longfin]

@dahlia @longfin Eh... this breaks linux-mono-build (not tests). Can you take another look?

Sure, I'll check again now.

[longfin]

@dahlia @longfin Eh... this breaks linux-mono-build (not tests). Can you take another look?

Sure, I'll check again now.

Opened the new PR(#2462) about that. cc @greymistcube @dahlia