2011/8/8 Ozkan Sezer <seze...@gmail.com>: > 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
Yeah, I once looked through your patch directory in your build source and never looked again. I was too afraid. >> 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 Ugh, even more. I don't think ppc is even supported by Apple anymore? > >> --> 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? Uh... this one currently, but it depends on how the builds are going to be done > >> --> 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? Yeah, a 7z .exe sfx thingie. If you have 7zip, you can open it as an archive, if not, you can double-click it and it will extract. Ruben ------------------------------------------------------------------------------ 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
