Completely static Windows build on CircleCI #9811
Conversation
ekpyron
force-pushed
the
windowsStaticCircleCI
branch
19 times, most recently
from
7ee3b98
to
02dbade
Compare
|
For the record: so far I get 3.5 minutes to build and install boost (and cmake) on cache mismatch, and <30 seconds for cache restore - but for some reason the actual solidity build takes a bit more than half an hour so far (which is more than in #9476 - and I'm pretty sure that cannot only be due to the completely static linking), so I'm still trying to figure out why that is and if it can be improved. |
|
The bulid times are still better than appveyor, aren't they? |
|
Actually with the So I think I'll extend this by the release logic and tests now. |
ekpyron
force-pushed
the
windowsStaticCircleCI
branch
from
02dbade
to
d66b6f1
Compare
ekpyron
changed the title
| @@ -25,6 +25,9 @@ set(ETH_SCRIPTS_DIR ${ETH_CMAKE_DIR}/scripts) | |||
| ## use multithreaded boost libraries, with -mt suffix | |||
| set(Boost_USE_MULTITHREADED ON) | |||
| option(Boost_USE_STATIC_LIBS "Link Boost statically" ON) | |||
| if(WIN32) | |||
| option(Boost_USE_STATIC_RUNTIME "Link Boost against static C++ runtime libraries" ON) | |||
There was a problem hiding this comment.
I'm actually not sure if this should default to OFF and only be set to ON in CI...
There was a problem hiding this comment.
Then again the boost binary distribution also doesn't have static libraries in general, so the same holds for Boost_USE_STATIC_LIBS above...
The problem is that linking entirely statically will only happen if one additionally uses -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded - but that again only works with CMake 3.16+ :-)...
I think otherwise building will also work (if a static boost library linked against a static runtime is found, like the one built by the new scripts/install_deps.ps1), but then boost will be linked against a static C++ runtime while solidity will link against a dynamic one, which is asking for trouble, unless both are compiled together using the exact same libraries... although it may be that MSVC has a stable ABI in the C++ library within each version anyways, so maybe it's fine...
Not sure how large the actual danger in all this is, though - and we can just take care to document all of this properly... So I guess we can merge this PR regardless, but I thought better to mention this - and we should at least update the docs soon after and before the next release.
There was a problem hiding this comment.
But defaulting to ON here will always break the existing AppVeyor builds, if we don't change the config for those :-)...
There was a problem hiding this comment.
I just pushed another commit setting that for AppVeyor to at least give it a chance :-).
ekpyron
changed the title
.circleci/config.yml
Outdated
| @@ -64,6 +67,11 @@ defaults: | |||
| path: build/solc/solc | |||
| destination: solc | |||
|
|
|||
| # windows binary archive | |||
| - artifact_solc_windows: &artifact_solc_windows | |||
| path: upload/solidity-windows.zip | |||
There was a problem hiding this comment.
Does it actually still need to be a zip?
There was a problem hiding this comment.
Well, currently it builds all binaries, so the compiler, the phaser and the upgrade tool...
If we only want to distribute solc.exe, then it doesn't need to be a zip file anymore :-). But it'd probably also break the new binary distribution scheme of @cameel's, wouldn't it :-)?
Weirdly enough the zip files of our previous releases did not include the phaser or the upgrade tool, but only solc.exe, the required DLLs and then soltest.exe for whatever reason...
There was a problem hiding this comment.
Hm... well... what to release generally is a different question from what to put up as artifacts here, though.
I could change it to upload the three binaries separately as artifacts? I don't mind either way.
There was a problem hiding this comment.
I don't think replacing the zip with an exe would be a big problem as long as it's still a single file. We have a file list so external tools will be able to find it. They just need to be adjusted to handle both possibilities and not try to unpack the exe. It would be nice to give some advance notice to tool authors but other than that the whole system is still fresh so adjustments should be understandable. The change does not break anything for the old releases.
There was a problem hiding this comment.
The reason for the zip file was the requirement to ship the dlls. If that is not an issue anymore, I think we should ship the .exe.
There was a problem hiding this comment.
Makes sense. And we can still decide and think about if and where and how we want to distribute the phaser and upgrade tool.
I'll change this PR to upload all three executables separately as artifacts in any case.
There was a problem hiding this comment.
When is the next release? If it's this week, then I'd keep it as a zip until then, not to introduce this change too suddenly... We'll need some minor changes in the update script for it to pick up the exe.
There was a problem hiding this comment.
we still have the zip from appveyor. I would not cut the appveyor run until after the next release.
|
Fine apart from the question whether we want the artifact to be a zip - but I think we can just merge as is now. |
|
Please note that this doesn't properly deal with the distinction between develop and release builds yet (i.e. it doesn't create prerelease and commit hash files yet) - I'll take care of that in a separate PR. |
Once this works I'll move some more logic to scripts - just checking how CI behaves so far.