differences between mingw32 and mingw64
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. There are several types of differences between win32 and win64 projects: 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 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) 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 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 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.) 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. Maarten -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
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
All of the non-intentional differences between win32 and win64
packages are gone now, so it should be easier to compare the two
repositories now.
2011/4/15 Fridrich Strba
On 15/04/11 16:38, Maarten Bosmans wrote:
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.
I have changed those to %{_mingwXX_bindir}/gspawn-*-helper.exe So the glib2 packages are the same again.
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 :)
Thanks for the explanation.
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.
Hmm yes, I see. A lot of our different viewpoints seem to come from our different use cases. You want to be able to build and install the mingw packages on all SUSE versions. I just want the BuildService to provide ready-build Windows binaries. (Hence I only enabled the OpenSUSE 11.4 i586 repository for my brached packages, because any more would be a waste of build cycles.) So for me the distinction between SUSE versions is meaningless and I see the two projects (win32, win64) as two different target platforms, which of course usually have the same (src) package name. So please, keep telling my why my proposals don't work, because there is a lot I haven't thought about. Well, let's set aside (or postpone) the merging of packages idea. How about just renaming the macros to drop the 32/64: _mingw_bindir for example. Then the mingw32-foo.spec and mingw64-foo.spec files would be exactly identical. For packages with intentional differences (like disabling java for win64) some %if macro could be used, just like when special casing for different distros. Then the only package that has a different specfile between win32 and win64 would be filesystem (and perhaps that pesky libqt). Without the need of sed, the automatic conversion of packages is even more fool proof (and I like that the differences are made explicit and not the result of a 10-minute sed/diff script), and that would be a nice starting point for evaluating whether further merging of packages is possible/desired.
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.
But practically always you don't commit to to one and leave the other untouched, but change both anyway.
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.
Maarten -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
participants (2)
-
Fridrich Strba
-
Maarten Bosmans