-
Notifications
You must be signed in to change notification settings - Fork 409
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release download script #35
Conversation
8af43b2
to
7da11e3
Compare
Script updated:
|
7da11e3
to
cf778c7
Compare
update
Outdated
@@ -11,7 +11,7 @@ const swarmhash = require('swarmhash') | |||
// This script updates the index files list.js and list.txt in the bin directory, | |||
// as well as the soljson-latest.js files. | |||
|
|||
var dirs = ['/bin', '/wasm'] | |||
var dirs = ['/macos', '/linux', '/wasm', '/bin'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this does not have windows because it does not have a circelci config, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, exactly. I wanted to take care of windows builds in a separate PR, when I can actually get them.
Should we include an architecture for linux, macos and windows? |
Good point, I think we should. We may want to support Mac OS on both arm and x86 at some point. I'd put that both in the file name and in the directory name. I don't have a strong opinion on how granular the directories should be - other than that they should not contain too many entries - so for now I'm going with the directories representing the things that are forced on you (system, platform, etc.) and slight variations that are up to your preference (i.e. static vs dynamic, gcc vs clang) would be kept in the same directory and just have different file names. |
To summarize the discusion from Gitter, this is the naming convention I'm going to use:
|
As said on gitter, I think we should start with the os instead of the architecture. Are we really using wasm32 instead of 64? Otherwise this looks good! |
Right. I updated the comment.
I'm not 100% sure but I think that's the case. @ekpyron confirmed it when I asked. I did a quick search earlier and I got the impression that wasm64 is still just on the roadmap. But maybe that was just about some specific implementation? Anyway, I'll check out build options to make sure. |
It's wasm32 - I think that's the only option that really exists today and is actually usable in browsers. |
@chriseth I'm trying to figure out if
None of the other jobs matches either:
Surprisingly, the Mac OS build is identical byte-for-byte. |
@cameel 0.6.11 is the only exception there - the scripts used different emscripten versions for that one, but usually that won't be the case. |
If CircleCI linux build is not static then why is it larger than the static one from Travis? |
While the CircleCI version is dynamically linked, it contains a static version of Z3, which is quite large - that's not in the "travis" build (although arguably it should be in the static release binary). |
ok. In that case it seems that everything is in order. I'll use |
You can't use that - that's dynamically linked :-). |
Oh, right, sorry. In that case: do we add a static build to CircleCI? An alternative would be to use one of @ekpyron's GH actions and fetch the binary from there (this would also ease the transition to fully automating it later). |
I think we should postpone this whole thing altogether for the time being - @chriseth also said on the gitter channel, that we don't really need this script for now, but rather need a directory structure, index files and hosting for the binaries (and we can just keep fetching the actual binaries manually from circleci, travis and appveyor, respectively from the release page the latter two will keep pushing to for now) |
0f43e24
to
80c24c3
Compare
I'm not sure if this will still be useful for anything so I'm leaving it as draft for now. It does work for MacOS and emscripten builds but obviously can't get static linux and windows ones because we don't have any. I salvaged the github part and put it into #41. I added some modifications there: downloading windows release, not running the update script, asm.js/wasm detection, etc. |
Maybe we can just close this. |
29c2692
to
e8565ae
Compare
80c24c3
to
5340440
Compare
e8565ae
to
ca4220f
Compare
5340440
to
1039e59
Compare
The script here is now a bit out of date (our artifacts changed, CircleCI has released API v2.0, etc.). I'm going to close this in favor of ethereum/solidity#12181, which reuses parts of this script. |
Part of ethereum/solidity#9258.
The script downloads latest release binaries for Linux, Mac OS and wasm from CircleCI. Files are placed in the following directory structure:
emscripten-asmjs/solc-emscripten-asmjs-<version>.js
bin/
emscripten-wasm32/solc-emscripten-wasm32-<version>.js
wasm/
linux-amd64/solc-linux-amd64-<version>
macosx-amd64/solc-macosx-amd64-<version>
windows-amd64/solc-windows-amd64-<version>.zip
TODO:
Make sureb_ubu
is the right source for the Linux build.latest
symlinks for Linux and Mac OS and make theupdate
script update them. Done in Emscripten releases #40curl: (3) bad range specification in URL position 2:
and continues).Don't overwrite binaries if they already exist (and maybe add a flag to force overwrite).