On 15/04/11 16:38, Maarten Bosmans wrote:
Hi list,
In order to understand the differences between mingw32 and mingw64 packages, I made a diff between all the packages in the two projects. To be able to compare the two, a script was used to rename all directories/files with mingw32 or mingw64 in the name to mingwXX and do the same replacement for contents of .spec files.
Let me comment inline :)
Unintentional whitespace differences or added empty lines, e.g. --- windows:mingw:win32/mingwXX-freetype/mingwXX-freetype.spec 2011-04-13 16:54:02.444618000 +0200 +++ windows:mingw:win64/mingwXX-freetype/mingwXX-freetype.spec 2011-04-13 16:53:57.968618000 +0200 @@ -14,7 +14,7 @@ -Source1: http://download.savannah.gnu.org/releases/freetype/freetype-doc-%{version}.tar.bz2 +Source1: http://download.savannah.gnu.org/releases/freetype/freetype-doc-%{version}.tar.bz2
Yeah, real whitespace differences should go. Like that one can synchronize better.
Unsynchronized versions, e.g. --- windows:mingw:win32/mingwXX-gc/mingwXX-gc.spec 2011-04-13 16:54:02.456618000 +0200 +++ windows:mingw:win64/mingwXX-gc/mingwXX-gc.spec 2011-04-13 16:53:57.980618000 +0200 -Version: 7.1 +Version: 7.2alpha4 (with corresponding different .tar.gz files)
Yeah, this one is particular one because the 7.1 is the current stable but is broken beyond repair for Windows x64. So, I chose to use for win64 the latest 7.2alpha4, but did not want to put alpha for win32, because I have on way to properly test regressions in boehm-gc.
Differences I'm unable to tell whether they are intentional or unintenional, e.g. --- windows:mingw:win32/mingwXX-gcc/mingwXX-cross-gcc.spec 2011-04-13 16:54:02.464618000 +0200 +++ windows:mingw:win64/mingwXX-gcc/mingwXX-cross-gcc.spec 2011-04-13 16:53:57.992618000 +0200 -%define include_java 1 +%define include_java 0
This is intentional, since java does not build for the time being for the x86_64-w64-mingw32 target. Pending upgrade of boehm-gc in gcc tree and some other changes. I prefered to have to change one define then to have completely different spec files. This is making trivial the sync process I will explain later.
Real differences in packaging that are correct, e.g. --- windows:mingw:win32/mingwXX-glib2/mingwXX-glib2.spec 2011-04-13 16:54:02.556618000 +0200 +++ windows:mingw:win64/mingwXX-glib2/mingwXX-glib2.spec 2011-04-13 16:53:58.084618000 +0200 -%{_mingwXX_bindir}/gspawn-win32-helper.exe +%{_mingwXX_bindir}/gspawn-win64-helper.exe
Yup, these are correct and complicate somehow my synchronization process.
Is there some (semi-)automated way to keep the packages in both repositories synchronized? That would prevent a lot of these little mistakes. (In general I'm quite unaware of what the workflow is to get both win32 and win64 packages. I only submit mingw32 requests and let Fridrich handle the rest.)
Typically I do following after accepting your request: 1) in the corresponding windows:mingw:win32 repository and corresponding mingw32-<package>, I do "osc update" which will bring the revision on the version of the accepted commit. I see the version as N. 2) I diff the change, modify the diff and test-apply to the corresponding mingw64-<package> "osc diff -r<N-1> | sed 's#mingw32#mingw64#' | sed 's#MINGW32#MINGW64#g' | (cd /the/corresponding/mingw64/package/path && patch -p0 -u -i - --dry-run) 3) If the test run succeeded or if it had only one or two hunks different, I do the same without --dry-run and fix the possible rejected hunks. 4) In case I see that the differences are meaningless, I do eventually in the mingw32 package directory: "for i in *mingw32*; do cat $i | sed 's#mingw32#mingw64#g' | sed 's#MINGW32#MINGW64#g' >/the/corresponding/mingw64/package/path/`echo $i | sed 's#mingw32#mingw64#g'`; done 5) After I build the package and fix eventual build problems. This is a reason why you will not find a patch called *mingw32*.patch it the packages, apart the mingw32-libqt4 package, where the patch actually is generated during upgrade from one to another version from the qt-<version>-mingw32.sh or qt-<version>-mingw64.sh scripts using wine and other tools and where the scripts are right to pass through my sed filter anyway :)
A possible (but quite intrusive) solution could be to rename all the packages to just a mingw- prefix (without numbers) and do the same for the rpm macros. That way all the packages in win64 could be branched of the win32 packages. For most packages this would just work and packages that need specific changes, those can be added to the mingw64 package.
No, a common mingw- prefix is not a good idea, I have on my machine both mingw32 and mingw64 development environments. Now, there is another idea to keep both the mingw32 and mingw64 files in the win32 repository and link them to the win64. I somehow kind of like something similar, but but there are two drawbacks. In the web-interfaces, if you fix a mingw64 spec file, it will be a new spec in the link and then if you are not careful, changing it again in the corresponding win32 package will not have effect. So again it is not flawless. Also, a commit to one will trigger the rebuild of both which might eventually be not a convenient stuff since we have more then 200 packages in each repository. I somehow still think that having two packages that are synchronized by human is for the time being better, but some simple solution that will not mean to uproot all and replant would be good to examine F. -- Please avoid sending me Word, Excel or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org