Hi, 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. An alternative I was thinking about here could be to use linux-host to do cross-cross builds. Means we build on linux first classical cross-compilers for each host (for mingw we can use the standard cross-compiler we would push as automated built). Then based on that we produce by them either 32-bit -> 64-bit cross-compilers, and doing canadian-cross for native variant. This task might have some disadvantages, as it requires more complex prerequists on build-hosts. Nevertheless it has also some advantages, as we would use our own stuff to build (as people say "eating our own food"). > 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? Well, beside for the head-version variant, I agree to this. But especially the built of head-version has a missing feature. Really usable for detecting regressions (beside something on built-process is broken) would be to run testsuite of binutisl and gcc, too. But for doing this in an endurable time means, we have to run them on linux-host via Wine. As a complete testsuite run of gcc - as example - takes on a native windows system using msys/cygwin more then 3-4 days. On a linux-box using Wine, it completes in about 4-6 hours. > 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. > 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. > 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. > 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, ...). > 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. > > 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. > > Thoughts? > > Jon I am all for it, I assume we all vote for this, too. We would need somebody taking action and bring it forward. Regards, Kai ------------------------------------------------------------------------------ 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
