The below is an email that I 100% fully support. Thank you, Jon. On Thu, Mar 22, 2012 at 12:15 PM, JonY <jo...@users.sourceforge.net> wrote: > On 3/23/2012 05:01, Jon wrote: >>> Would it be possible to generate a new automated build for mingw? If >>> I remember correctly the mingw build-bots were down? >> >> Perhaps it's time to rethink the current automated build strategy with an >> eye on dramatic simplification. Something that's less onerous, less complex, >> and more in line with the current project resourcing realities. >> >> Buildbot may be great for CI, but is it overkill for automated release >> builds? >> >> How often are automated builds really needed? Once a week? Once a month? >> Once a quarter? >> > > Done everyday. > >> Are binary downloads for multiple platform types really necessary if great >> build wiki documentation is available and maintained? >> >> 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. >> > > No need for recipes or what not, there is already an existing puss > button buildsystem. All that is needed is a VM with good uptimes. > >> 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. >> >> 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 >> > > We really not like to add all the extras to the automated builds, last I > heard, the build slaves network bandwidth is limited. > >> Of course it would use shell coding, not Ruby, but you get the point. >> >> I've recently cloned Ruben's github repo and had hoped to make time to >> submit code specifics, but we all know how that story often unfolds. > > As for buildsystem configuration testing, please look into > makebuildroot.mk and makebuildroot-test.mk in /experimental/buildsystem. > > The former is followed closely by buildbot. The latter does all the > whizzbang like winpthreads, libgomp etc. All the config is near the top. > The 2 makefiles diverged a bit after some time, with the latter aimed > for the user who wants this-and-that included in his build. > >> >> 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. >> > > In short, we need more build slaves machines to mitigate the effect of a > downed machine, volunteers and donations are welcome. > > > > ------------------------------------------------------------------------------ > 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 > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >
------------------------------------------------------------------------------ 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
