> it would be very good if we could provide new mingw-hosted builds. > Sadly are our buildbots for those architectures (cygwin, mingw) down. > So we need to find an alternative for them. > > 2012/3/22 Jon <[email protected]>: > >> Would it be possible to generate a new automated build for mingw? If > >> I remember correctly the mingw build-bots were down? > > The automated builds - at least those against head-versions of all > used ventures (gcc, binutils, mingw-w64) - were intended mostly for > detecting fast regressions on head-versions. I admit that the > frequency of 1 time per week for head versions would be ok, too. The > versions against release-branches could be done even less frequent, as > it is here just of interest to rebuild those, if something has actual > changed. > > So question is what version combinations we want actual have regular > built and provided in automated way, and at what frequence.
I like that idea...let's use "regular release build" to mean mingw-w64 project release builds for end users, and not overload the "automated build" phrase. My strawman is strictly limited to "regular release builds" which would be viewed as the official mingw-w64 project release builds. These regular builds are the one's other projects like blender, et al would refer to in their doco when showing how to build with mingw-w64. Any automated builds from buildbot would continue to be useful for mingw-w64 committers for fast detection of regressions, test suites, etc on head versions, but the automated builds are not meant for users. They're meant to be internally consumed by mingw-w64 contributors. The key risk is potential divergence between internal mingw-w64 automated builds and external regular release builds. It may seem like extra work that buildbot is perfectly capable of doing. While that may be true, the fact remains that the buildbot driven release build process isn't working very well. My view is that it's great as a CI but is too heavyweight for regular release builds. Because it's too heavyweight, it's not being updated and maintained and no one wants to mess with it. Bottom line: extract the regular release build responsibility from the buildbots into something more lightweight and more maintainer friendly. Ruben's already done most of the heavy lifting. > > How often are automated builds really needed? Once a week? Once a month? > > Once a quarter? > > Well, trunk builds are those which should have highest frequency IMHO. > As I described above, they are nice for finding explicit > build-failures, but lacking to detect regressions early. > > The version build against branches should be IMHO built only on > demand, if something has actually changed. I should have said regular release builds and not overloaded "automated builds." I think most users would be happy with once a month release of official 32/64bit mingw binary builds. > > Are binary downloads for multiple platform types really necessary if great > > build wiki documentation is available and maintained? > > Having a great Wiki-page is of course something good. But we should > provide some prebuilt host-versions, too. It allows users to try it > on their machine, without the need to do a complete bootstrap > themself. So I would think that as host-architectures linux 32/64, > darwin, and mingw 32/64 would be desired. For the later two > host-builds a setup would be of course desired, too. Agreed that would be great. But trying to provide all of those appears to have become too burdensome and has therefore stopped. I also think most Linux and Darwin users are more comfortable building from source and would be OK with bootstrapping a plain vanilla host-version themselves as long as the Wiki page was clear and maintained. IMO, it's the native mingw 32/64 users who most benefit from prebuilt host-versions. I really think the challenge is to keep from taking on too much and getting overloaded :) > > IMO, it's time to focus on something foundational and sustainable. As a > > strawman for discussion, I'm thinking of: > > > > 1) automated binary downloads once a month for only plain vanilla > > i686-w64-mingw32 and x86_64-w64-mingw32 native builds. > > 2) high-quality wiki documentation for building plain vanilla on Arch, > > Ubuntu, FreeBSD, and OSX. > > 3) no changes to the existing personal builds (actually, I'd like to see > > Ruben copy Ozkan's excellent README summary available on the sezero SF > > download pages) > > 4) automated "official" build recipe based upon Ruben's > > https://github.com/rubenvb/MinGW-w64-build-scripts The two official > > automated builds (x86, x86_64) should be able to be built by _anyone_ using > > (at a minimum) a recent Ubuntu system or Ubuntu running under a VM on > > Windows. This isn't to say other platforms can't be used, but the baseline > > is Ubuntu (Server?). Even though we all know Arch is the One True Distro, > > it's probably too edgy for use as the baseline build platform. > > Sure, we would be all happy by it, if we could make this happen. > > > FWIW, ~6 months ago I dug through Ruben's and was impressed with the > > potential for using as the build recipes for semi-automated "official > > builds." The two concerns I had then were (a) configuration setting, and > > (b) automated repo source downloads/updates as part of the build process. > > Well, the source-ball we need to provide for each set of binary builds > of a specific version combinaion. This is required by GPL for > binutils and gcc, so we have to do that. It was always my hope that if the regular release build recipe provided explicit version combination configuration info and provided a way to download source via svn, git, wget/curl the source-ball wouldn't be needed. Anyone simply runs the build recipe and it downloads whatever source is needed. The declarative configuration info is self-documenting (URL, version, etc) for dependencies. That said, you all have discussed this ad-nauseam in recent posts so I need to review in more detail. > > By "configuration setting" I mean, easy declarative configuration setting > > like: > > > > https://github.com/oneclick/rubyinstaller/blob/master/config/devkit.rb#L27-65 > > https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingw64.rb#L40-73 > > > > Of course it would use shell coding, not Ruby, but you get the point. > > For *nix based hosts, or at least using a POSIX environment on > Windows, this is a good idea. For native builds, we might need an > installer (NDIS, Sherpa, ...). No, no. An installer over complicates things at this point. Sorry I wasn't clear. My declarative configuration example was only meant to show one way to specify dependents and versions and only used internally with Ruben's existing build infrastructure. You need an easy way to specify source repos/download URL's, version, etc that other parts of the build recipe use to download/update/patch the source in preparation for building. You want to be able to lock down specific branches/tags/commits rather than always using head from trunk/master. I don't know how Ruben does it currently, but my guess is that he munges the source directories/repos first (maybe just always uses head) and then runs the build script. Declarative build configuration and svn/git/curl abstraction would hopefully be able to automate most of the manual munging. > > This email is long enough, but I'd like to hear if you think the idea has > > legs and what needs to be morphed. Specifically, what are the few specific > > TODOs and who (other than the overworked project committers) are able to > > take ownership of the tasks. > > > > Regardless, I feel strongly about four things: > > > > 1) This project needs regular, high-quality automated "vanilla" binary 32 > > and 64bit mingw builds in addition to the personal builds. > > 2) This project needs high-quality wiki build instructions for other > > platforms. > > 3) The bulk of setting up and maintaining any new automated build process > > needs to _not_ fall primarily on Kai, Jon Y, or Nightstrike by default. Of > > course they'll be involved, but the bulk of the work should be done by > > interested contributors. > > 4) Any new automated build process must be fairly easy to perform, and > > generic enough to be easily transferred to a new maintainer. > > I am all for it, I assume we all vote for this, too. We would need > somebody taking action and bring it forward. That's the key. Unless the idea get's refined enough to attract contributors willing to donate their time, and the workload gets parallelized, the idea is effectively dead. Jon ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
