Re: [Mingw-w64-public] New automated build for mingw?

[Jon <jon...@gm...>]

> > I'm not against CI, but I think something more lightweight, something more attractive enough to potential new maintainers, and something easily replicated/setup for only official project release builds is the solution. And buildbot doesn't go away, it just gets used internally by you and the other committers for fast regression testing.
> >
> 
> It's down most of the time because the buildbots are leased on a
> volunteer basis without any regard to support capability. We also do not
> have any physical access to them, which limits us to sending ping emails
> to the machine owner to recover it.

Ah, that is very unfortunate.


> IMHO, we simply need a canned VM appliance that we can push to our
> volunteers, that way, we can quickly replicate our build slaves. As new
> maintainers come in, we just tell them to stick the appliance into their
> VM while we register the new slave.

A canned VM is a great idea. I think untethering it from the buildbot for regular release builds will turn out more maintainable in the long term. I'd like a canned appliance in which one simply clones an updated Ruben repo and builds. Forget buildbot masters, slaves, configuration, and registration. Control access by giving only the current release manager the ability to upload to SF. Not fully automated, but highly automated.

That said, short term, I wonder if a similar idea could help to quickly get the mingw binary builds up and working while we discuss longer term ideas.

Specifically, configure local buildbot networks on a single computer using a network of VMs.  For example, I have a Win7 32bit notebook with 4GB on which I simultaneously run both an Arch VM and an Ubuntu Server VM using VirtualBox. Each VM has eth0 NAT'd to the Win7 host (with SSH port forwarding) and eth1 on a private 192.168.*.* local network. The VMs communicate on the local network via SSH, etc.

Can we sidestep the current physical buildbot problem by running a buildbot master in one VM and a slave in another VM all on one machine and start generating regular 32bit and 64bit mingw builds again?

As you can imagine, I think this is a horribly complex "fix", but it could be interesting short term.

Also, it will be interesting to see what Vincent Torri might be able to do wrt additional build resources.


> >> As for buildsystem configuration testing, please look into
> >> makebuildroot.mk and makebuildroot-test.mk in /experimental/buildsystem.
> >>
> > ...SNIP...
> 
> Both Makefiles are usable by the user, assuming the user has all the
> prerequisite host programs already installed, it'll pull all the gcc
> deps and build it from source.

I snuck away and looked at both today. I see why you want to try to leverage this previous work if at all possible. IMO, it needs tweaks to make a much more usable release build, but that's another topic.

Jon