On Mon, Aug 8, 2011 at 6:02 PM, Ruben Van Boxem <vanboxem.ru...@gmail.com> wrote: > Dear mingw-w64 developers, > > You guys rock, let that be clear ;-) > > Kai and me have been discussing a proper release build setup for > mingw-w64. I would become the release packager dude that makes sure > proper releases are... released. > > I would like to make some things clear first: > > - Linux binary releases made here are never going to be picked up by > distro's. They like to build everything themselves. I say let them, > but that diminishes our control of a proper (and compatible) set up. > - Autobuilds are made for the devs, and helpful to them. They should > be moved to a more remote location on the mingw-w64 site to not > confuse regular users > > The current plans are: > > - Build proper full fledged toolchain releases. This means: > --> A full-fledged mingw-w64 crt (all optional SDKs included) > --> A full-fledged GCC: (obj-)c(++), fortran, ada, with OpenMP and > Graphite support. > --> winpthreads included > --> make and gdb with python enabled as well > - What we agreed on about versioning: > --> mingw-w64 should adopt a semi-rolling release model. It's > source only, so (Linux) packagers should just pick a (release) branch > and use its latest revision. > --> binutils: latest trunk is the only sensible version > --> GCC: latest stable versions, meaning the latest released version. > --> Each mingw-w64 toolchain release will happen for each GCC > release, and this over (currently) the 4.5 and 4.6 branches.
> 4.4 is > not x86_64-w64-mingw32 ready yet, so it's quite senseless to use that. The 'yet' part is not needed: mainstream 4.4 will never be ready without proper patching > Each new GCC minor version will ideally be accompanied by an update on > mingw-w64 release side. > - host/target support: > --> multilib is tough to use correctly, and the world is just not > ready for this awesomeness > --> No multilib means two binary packages for each host, one > targetting i686-w64-mingw32 and one x86_64-w64-mingw32 > --> Hosts would be 32-bit Windows (i686-w64-mingw32), 64-bit > Windows (x86_64-w64-mingw32), 32-bit Cygwin(i686-pc-cygwin), 32-bit > Linux (i686-linux-gnu), 64-bit Linux (x86_64-linux-gnu), > 32-bit Mac OS > X (?), 64-bit Mac OS X (?) This you assume the osx host being x86-compatible. You can add ppc[64] ones, too if you want > --> Sums up to 14 binary packages. > - Details: > --> I plan to build all prerequisites statically, prevents missing > dependencies on Linux etc... (which often do not have tha latest > cloog/ppl/gmp/mpfr/mpc) Only glibc then. What glibc version will your linux build hosts have? > --> Mac/Linux/Cygwin packages would be bz2 or lzma tarballs. > --> Windows would have self-extracting 7z archives. This is a > compromise between a missing installer and a large zip file. A small > batch file (like mingw32vars.bat in mingw.org releases) will be > included for handyness. Possibly a zip/sfx? > > Unless there's a way to cross-compile from linux to mac, I'd need > access to build machinery. Maybe it would be best to get the releases > set up on some common infrastructure anyways. > > In conclusion, the releases will closely resemble my latest Personal > builds, which isn't a coincidence ;-) > > Any constructive thoughts are welcome, and help in getting the > machinery set up. In my eyes, this would mean making my scripts > runnable on some build infrastructure, and expanding them to work for > Cygwin/Mac, hopefully without much trouble. > > Cheers! > > Ruben -- O.S. ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
