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.


Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
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

Reply via email to