> > Where's the source for this automated build recipe? I'd like to look it > > over to determine if I've got enough time to work up patch series for your > > review that does the following: > > Hi; sorry about the delay. The automated builds are done via this makefile: > > http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/buildsystem/makebuildroot.mk?view=markup > > That is in term driven by buildbot, the configuration is here: > > http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/buildbot/
@Mook...thank you. > > 1) Strip -s on all exes. I maintain a build recipe at > > https://github.com/oneclick/rubyinstaller which aggregates MSys and the > > latest mingw-w32-1.0-bin_i686-mingw_* download into what we call the > > DevKit. Currently this explodes to ~758MB on-disk. After stripping just the > > mingw-w64 exes using something similar to the following, the on-disk size > > shrinks to ~328MB. > > > > for /r mingw %F in (*.exe) do strip -s %F > > This is what the install-strip make target is for. Don't do it > manually. Just call make install-strip instead of make install. For the automated mingw downloads, I believe the exes should be stripped either as part of a deployment target or `make install` given the massive size differences. Download users (rather than source builders) will never run `make install-strip`. The only reason I see not to `strip -s` the exes for the downloads is if the missing info causes problems. For me, the real issue is what are the benefits of keeping all the info in the exes, and is it worth the large storage and download sizes? Your call of course, but so far in my use cases I get negative benefit from the large exes. > > 2) Add prefix-stripped (eg - gcc) exes to the download to accompany the > > prefixed (eg - i686-w64-mingw32-gcc) exes. > > Why? Not all downstream packages or users play well with the prefixing http://hg.python.org/cpython/file/4feb889d3bed/Lib/distutils/cygwinccompiler.py#l296 and when building packages that do play well http://code.google.com/p/vim/source/browse/src/Make_ming.mak#317 it's unnecessarily cumbursome (and an unexpected cross compile when building-for-win-on-win) to have to have to build like the following make -f Make_mingw.mak gvim.exe xxd/xxd.exe CC=i686-w64-mingw32-gcc WINDRES=i686-w64-mingw32-windres And if you're trying to automate the building of a package with multiple dependencies and support multiple toolchains, you can get into the situation of doing truly horrific things like https://github.com/oneclick/rubyinstaller/blob/master/recipes/devkit/devkit.rake#L63-71 That's why I think shrinking the download size by stripping and having both prefixed (prefixed binutils exes probably not needed at all a la Ruben's build) and non-prefixed exes in bin/ is better than the current situation for the mingw (build-win-on-win) download flavor. > > 3) Compress the final download using LZMA2 to a *.7z similar to what Ruben > > provides. Given the robustness and availability of the 7-Zip project, I > > don't believe there's a good reason to stick with zip's for Windows users. > > zip on windows is available without any 3rd party utilities. Any > windows user can extract a zip, and zip is understood everwhere to be > a windows archive. I see no reason to change that just to gain a few > megs off an archive. The bigger issue, and the one we should > concentrate on, is the duplicated lib directory. Valid point, and I agree with the higher priority issue. That said, IMO it would be a big win to do both as (a) mingw-w64 users are developers rather than normal users so 7z being a 3rd party utility is really a don't care, (b) it's more than a few megs savings as I've shown, and less compellingly, (c) other developer focused downloads including mingw.org are switching to *.lzma and *.7z for their windows downloads. Jon --- blog: http://jonforums.github.com/ twitter: @jonforums "Anyone who can only think of one way to spell a word obviously lacks imagination." - Mark Twain ------------------------------------------------------------------------------ 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
