On Mon, Aug 8, 2011 at 6:31 PM, Ruben Van Boxem <vanboxem.ru...@gmail.com> wrote: > 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
Just noticed this one: be careful with windows builds of make, you may need to patch it to make it operate correctly on windows (see the one we are distributing) >>> - 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? > Possibly no, however there are still many pc machines running around. I wasn't requesting anything, though, was just reminding. >> >>> --> 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. Umm, I meant a real zip-sfx (self extracting zip which you can actually run through unzip.) Howver, 7z should be acceptable too. My main point is, once in a while people (I) download a windows package while on linux and still want to extract and play with it. So if the windows packages will be easily extractable (please no cab or any native windows variant), then good. > > 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
