Closed tgerring closed 7 years ago
Script for testing with Powershell 3.0 and up: https://gist.github.com/tgerring/b93057e06960d906574c
GMP dependency removed in #2037 makes building easier. Here is an updated script for building with MingW via Cygwin: https://gist.github.com/tgerring/79f018954aadfb3f406e
Eew ... instructions which are not automatable are nasty! Well good luck with this issue. I am also largely Windows-free myself these days.
The second PowerShell script I linked should work on all PowerShell 2.0+ installations (Windows XP SP3 up through Windows 10) and will attempt to install missing dependencies. This can be run directly on a fresh install of Windows and will result in a Geth installation.
This should be sufficient for creating a build-from-scratch Chocolatey script or Appveyor build
Thanks.
But that is not currently running anywhere, right, because of your afore-mentioned lack of a Windows box? Good to know.
All Go automation is at https://build.ethdev.com/, right? And Python, plus other bits-and-pieces, but not any C++, though there used to be some several months back.
@LefterisJP pointed me at http://52.28.164.97/, which is the Jenkins instance for C++ which I am aiming to clone or make an equivalent of for the C++ cross-builds:
See https://github.com/doublethinkco/webthree-umbrella-cross/issues/44
I've asked both @chriseth and @obscuren to have a pow-wow about builds so we can have a less patchwork approach. Right now, Windows is often lagging behind which is probably okay for Frontier, but for greater adoption in Homestead, we need better support of many platforms including Windows and mobile
Great! If there's anything I can do to help, please do feel to drag me in, guys.
I worked on automated builds at industrial scale for EA for more than a decade. I would like to see Ethereum builds in a robust and healthy state.
I registered the http://ethbuilds.com domain too, if we need a new "commons" for builds outside of ETHDEV? I assume that Slockit, Ethcore, Consensys and others will also have an interest in such basic infrastructure too.
I'm confident the scripts I posted offer compelling solutions to close out this issue. The remaining question is what to target, either maximum compatibility back to WinXP SP3 32-bit (Powershell 2) or a more recent Win7 64-bit (Powershell 3).
Although the maximum compatibility script will work on all versions of Windows, it does not appear that the 32-bit binary works despite the build not failing. Is it worth preserving compatibility worth it in this case or would it be be better to drop support for non-working builds and target the future?
The main differences are in supported version of Powershell. PS 3 allows for built-in unzip and downloader, whereas with PS 2, we add "unzip" as a dependency and relegate downloads to the .NET CLR (as integrated in Powershell). Both of these are only used for setting up the initial build dependencies. Once satisfied, neither of these issue matter.
I personal would love if we could support win 32bit, as many people still have it and mist can deliver there too. But it shouldn't then require to much overhead, or hacks.
Well ... any automation is better than no automation, so why not start with getting your Powershell 3 solution running, and make a new issue for the lack of Windows 32-bit support?
@frozeman 32-bit build succeeds but resulting binary doesn't appear to run. I tried to track down what exactly is going on with @Gustav-Simonsson a while back, but we were largely unsuccessful. Barring a true expert Windows developer, I don't know that this is going to be solved soon
@bobsummerwill Both PS2 and PS3 solutions work but WinXP SP3 only supports PS2. I have not tried to build 32-bit on Win7 or higher (if this is even available).
Right now, the most robust script is the second Gist linked at https://gist.github.com/tgerring/79f018954aadfb3f406e. It runs on all supported Windows versions and some that are already EOL'd. My nomination would be to PR it to the build directly until we can concretely say a move to PS3+ makes sense
And you still haven't gone-live with this, right? Still because of lack of hardware? Or just not got around to it?
Currently, there's no pressing need as we have a Windows server in place. The main benefit would be easier access to the community at large without having to depend on Ethereum proper to produce binaries.
And presumably the buildbot automation is plopping out ZIPs/EXEs continuously anyway?
Yes, however this is the weak point compared with Linux, since we use the free Travis service, which could produce binaries in the event of buildbot failure. Similarly, Appveyor could be used on the Windows side with a proper setup & build script.
Right. Thanks for the extra context!
Just to confirm, @tgerring, this script still isn't live, right? I'm just looking through our Chocolatey/NuGet TODOs on C++ now.
@bobsummerwill Correct that this has not been merged. I've requested reviews/tests a few times now but before adding ad-hoc build scripts, it would be good to ensure it meets the needs of the team
Gotcha.
Also, just looking back through the comments, @frozeman mentions 32-bit builds. I just answered two people on the welcome gitter looking for 32-bit Mist. We're getting them for eth as well.
With the seeming >50% of people who are coming to Ethereum from Windows, a number of them only have 32-bit machines. There does seem to be a need. Just FYI.
I'm just going to jump in on the 32 bit part.
I'd say that the handful of people running 32bit systems are out of luck. Ethereum was build for the future and not for the past. I don't think it's worth it supporting almost legacy systems. Almost all new devices and hardware that's coming out is running 64bit architecture.
A bit of an arrogant statement but; if the demand for ethereum is high enough people will update their legacy systems.
Yeah, I hear you, @tgerring.
I added We only support 64-bit builds in many places in the C++ instructions - http://www.ethdocs.org/en/latest/ethereum-clients/cpp-ethereum/index.html#installing-and-building - but I have really been surprised at how many requests for 32-bit support we get.
This kind of language ... " We only support 64-bit builds.
It may be possible to get the client working for Windows 32-bit, by building from source and disabling EVMJIT and maybe other features too. We might accept pull-requests to add such support, but we will not put any of our development time into supporting Windows 32-bit builds. "
I guess it boils down to support cost. If it "just works" and we can just run some more automated builds then maybe it's worth considering. If it's a pain in the arse then sod it.
In my mind it's much like the profusion of Linux distros. I would love to just say "you're on your own" for all those, but with just a bit more effort we can win some people over, but it's mainly letting them self-support and not hindering them from doing that. "Hey! Maybe you could write a Wiki page for how to build for your distro?"
Maybe we just need some mechanism for enabling "Windows/Linux 32-bit people" to collaborate on supporting this stuff for themselves? Or not!
Just after typing that, I just answered yet another request for 32-bit support (this time for Wallet) on https://gitter.im/ethereum/welcome.
Just so it's documented, the Powershell script linked here DOES produce a 32-bit Windows binary without error, however, it immediately shuts down with no log, Windows exception or the like. I spent some time with @Gustav-Simonsson trying to watch process monitor to look for an obvious problem, but we weren't able to track it down.
@bobsummerwill can you point me in the direction of the C++ installer bits? I'd like to take a look and see how hard it would be to incorporate it into the Powershell script
RE: Geth 32-bit shut down. Yikes!
This appears to be where the C++ installer is (https://github.com/ethereum/webthree-helpers/blob/develop/cmake/EthExecutableHelper.cmake#L166) - just a call to NSIS target. I've done nothing with it myself yet. Not sure how it is invoked. http://ethbuilds.com points to the Jenkins instance. It will be some target inside that.
windows builds are now automated on appveyor
Do you do creation of chocolatey packages for go-ethereum
?
That is one step which we are missing for cpp-ethereum
, but which I would like to add.
Or are they still disabled, as per ...
The windows building from source are not machine processable. Ideally we can provide both a Chocolatey package and appveyor.yml to enhance CI.