macOS build action workarounds for newer Homebrew and Clang

[cameel]

Related to argotorg/solidity#10183. Replaces #73.

Just a bunch of workarounds to be able to still use the action.

The old way of installing boost no longer works because homebrew has removed the option to install from a local script. You can now kinda do this by creating a tap and you can kinda create a local one (even though Homebrew pushes you hard towards publishing it on github) but with so many workarounds needed, it was actually easier to just build from source.

Also, unfortunately newer Clang also requires patching Boost build system to be able to build it.

[chriseth]

What is this? This is horrible! ;)
Why is this not an issue with https://github.com/Homebrew/homebrew-core/blob/master/Formula/solidity.rb or https://github.com/ethereum/homebrew-ethereum/blob/master/solidity.rb ?

[cameel]

It's basically what the original Homebrew formula was doing plus some patches because those old Boost versions had a small bug related to build flags that now prevents them from compiling with newer Clang. Yeah, it's pretty horrible. The whole situation with older versions of Boost in Homebrew is hopeless but I can understand them not wanting to support older versions due to limited manpower.

Why is this not an issue with https://github.com/Homebrew/homebrew-core/blob/master/Formula/solidity.rb

They only support the latest version of Boost. It used to be possible to select an older version in the past but they stopped tagging them after 1.60. It was still possible to download this formula from an older commit and that's what I've been doing but in the current Homebrew even that does not work. I almost got it to work with an older commit by creating a local tap but I could not get over the last problem and finally I decided to stop doing shell acrobatics with Homebrew and just build it from source myself.

or https://github.com/ethereum/homebrew-ethereum/blob/master/solidity.rb ?

I think this also builds latest Boost. It can get away with it because it only needs to work with modern Solidity versions. I could have done that too for the newer builds but for the older ones I would still I need older Boost.

[chriseth]

I'm a bit lost. Can you explain what this action does in general?

[cameel]

Sure. Here's a general outline, with steps modified in this PR described in more detail:

1. Grabs the list of tags from github API, removes those that already have a matching binary in macosx-amd64/ an chooses one of the remaining ones at random.
2. Checks out the solidity repo at the selected tag.
3. If osx_install_dependencies.sh exists, uses it to install dependencies. Otherwise it has to do it on its own:
   • Builds 1.66.0 boost from source
     • Downloads the official source tarball
     • Patches the Boost source to disable -fcoalesce-template and -Wno-long-double flags, which are not supported on Clang (there's a bug in this version of Boost that results in the flags being misdetected a supported in Clang 11.4+).
     • Runs the build using Boost's custom build system (bootstrap.sh and then b2 install)
     • Built Boost is now in a local directory. Since dynamic libs are not in the system directory, the local directory is added to DYLD_LIBRARY_PATH.
   • Downloads pre-built release of Z3 4.8.5 and puts it in a local directory
   • For solc 0.5.11 and up also downloads pre-built evmone 0.1.0 for use in tests.
4. Formats a full version string for the binary we're building
5. Based on solidity version applies patches to the source and/or selects build options.
   • If Boost was built from source, adds options to force cmake to use it.
6. Runs cmake and make with selected options.
7. Uploads the binary as an artifact.
8. Uses otool (macOS equivalent of ldd) to print the list of dynamic libraries the binary is linked with so that you can see it in the logs from the action.
9. Does some more patching/option selection to be able to run tests
10. Runs scripts/tests.sh if available and works. Otherwise falls back to running cmdlineTests.sh and soltest explicitly. On versions where even that won't work, just does a smoke test by running solc on the simplest possible contract.
11. Pushes the binary to solc-bin repo.

Initially I thought this action would be a one-off but now I see that it could be more useful in the future (e.g. for the ARM builds). Do you think it would be worthwhile to split it into individual Bash scripts and put them into scripts/solc-bin/ in solidity repo? In a separate PR of course because I don't really want to do drastic changes here since binaries were already built using what I have in this PR.

[chriseth]

Ok, thanks for the explanation! Yes, I think we should try to keep the CI config files small in general and put everything that does not really depend on the CI logic in scripts (unless it is just 2-3 commands of course).