ethereum
Use submodules for some dependencies.
We also need to update the build scripts, like build.sh. But I'm wondering why not just add the git submodule update --init in the CI build script and consequently all CI steps that build the code would already setup the submodules in the beginning of the build process.
Actually, maybe even better, I think we could do all in cmake using execute_process, something like:
find_package(Git)
if(Git_FOUND)
execute_process(COMMAND git submodule update --init ...)
...
endif()
And also add the error message as suggested by @clonker if the submodules are not initialized correctly.
At least scripts/release_ppa.sh will also need adjustment - although we can do that separately, we'll have to confirm that that works with a prerelease PPA build - but we shouldn't forget in any case. Might be worthwhile to check if any other release build mechanisms also need adjustments, resp. to confirm that they work (like docker builds and such)
Actually, maybe even better, I think we could do all in cmake using execute_process, something like:
find_package(Git) if(Git_FOUND) execute_process(COMMAND git submodule update --init ...) ... endif()And also add the error message as suggested by @clonker if the submodules are not initialized correctly.
I think this was a really good idea! It simplified this PR a lot, we don't need to initialize the submodules explicitly anymore.
Ok, I just tested the resulting source archive with homebrew: The build of the old version failed as expected:
==> Fetching solidity
==> Downloading https://github.com/ethereum/solidity/releases/download/v0.8.25/solidity_0.8.25.tar.gz
==> Downloading from https://objects.githubusercontent.com/github-production-release-asset-2e65be/40892817/eb9d3485-38fd-4b46-8736-508fef9fb1af?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetproduction%2F20240717%2Fu
################################################################################################################################################################################################################################ 100.0%
==> cmake ..
Last 15 lines from /Users/alex/Library/Logs/Homebrew/solidity/01.cmake:
-- Found Boost::program_options at
-- Found Boost::system at
CMake Error at /opt/homebrew/Library/Homebrew/cmake/trap_fetchcontent_provider.cmake:12 (message):
Refusing to populate dependency 'fmtlib' with FetchContent while building
in Homebrew, please use a formula dependency or add a resource to the
formula.
Call Stack (most recent call first):
/opt/homebrew/Cellar/cmake/3.30.0/share/cmake/Modules/FetchContent.cmake:2468:EVAL:1 (trap_fetchcontent_provider)
/opt/homebrew/Cellar/cmake/3.30.0/share/cmake/Modules/FetchContent.cmake:2468 (cmake_language)
/opt/homebrew/Cellar/cmake/3.30.0/share/cmake/Modules/FetchContent.cmake:2314 (__FetchContent_MakeAvailable_eval_code)
cmake/fmtlib.cmake:19 (FetchContent_MakeAvailable)
CMakeLists.txt:46 (include)
-- Configuring incomplete, errors occurred!
[...]
The new source archive seem to work as expected (no warning regarding FetchContent) However, I'm not able to build it on my machine - it looks like that boost does not contain arm64 for some reason. Not sure why.
==> Fetching solidity
==> Downloading file:///tmp/solidity_0.8.27-nightly-2024-07-16-a4d611be.tar.gz
Already downloaded: /Users/alex/Library/Caches/Homebrew/downloads/e143f92127cf47889e18123dcf7a0e82aae2c0cf2f03fbccb7db6fb2dfcf19cc--solidity_0.8.27-nightly-2024-07-16-a4d611be.tar.gz
==> cmake ..
==> make install
Last 15 lines from /Users/alex/Library/Logs/Homebrew/solidity/02.make:
"boost::filesystem::detail::canonical(boost::filesystem::path const&, boost::filesystem::path const&, boost::system::error_code*)", referenced from:
solidity::test::isValidSemanticTestPath(boost::filesystem::path const&) in Common.cpp.o
solidity::frontend::test::CommandLineInterfaceTest::cli_input::test_method() in CommandLineInterface.cpp.o
solidity::frontend::test::CommandLineInterfaceTest::cli_input::test_method() in CommandLineInterface.cpp.o
solidity::frontend::test::CommandLineInterfaceTest::cli_ignore_missing_some_files_exist::test_method() in CommandLineInterface.cpp.o
solidity::frontend::test::CommandLineInterfaceTest::cli_paths_to_source_unit_names_no_base_path::test_method() in CommandLineInterface.cpp.o
solidity::frontend::test::CommandLineInterfaceTest::cli_paths_to_source_unit_names_no_base_path::test_method() in CommandLineInterface.cpp.o
solidity::frontend::test::CommandLineInterfaceTest::cli_paths_to_source_unit_names_base_path_same_as_work_dir::test_method() in CommandLineInterface.cpp.o
solidity::frontend::test::CommandLineInterfaceTest::cli_paths_to_source_unit_names_base_path_same_as_work_dir::test_method() in CommandLineInterface.cpp.o
...
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [test/soltest] Error 1
make[1]: *** [test/CMakeFiles/soltest.dir/all] Error 2
make: *** [all] Error 2
However, I guess we could just ignore that. Building manually from source is working without any problems.
Ok, I found the problem: I had two conflicting boost versions installed. After removing the "old" version, everything works as expected:
==> Fetching solidity
==> Downloading file:///tmp/solidity_0.8.27-nightly-2024-07-16-a4d611be.tar.gz
Already downloaded: /Users/alex/Library/Caches/Homebrew/downloads/e143f92127cf47889e18123dcf7a0e82aae2c0cf2f03fbccb7db6fb2dfcf19cc--solidity_0.8.27-nightly-2024-07-16-a4d611be.tar.gz
==> cmake ..
==> make install
🍺 /opt/homebrew/Cellar/solidity/2024-07-16: 8 files, 45.0MB, built in 1 minute 47 seconds
==> Running `brew cleanup solidity`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
Oh, one more thing. Once we merge this, it would be good to have a follow-up PR with an update to latest versions of these libraries. Especially range-v3 seems to be already at 11.x, while we're still on 9.x.
