The virtual mingw32(...) and mingw64(...) provides used to be generated
from the names of WINE DLLs. This changes it to generate the list from
mingw-crt import libs instead. The advantage with the new approach is
that we can be sure that the virtual provides match with the actual DLL
names we can end up linking with: we'll be linking with the same stubs
from mingw-crt package that are used for the virtual provides list.
So far each individual spec file has had to define mingw_build_win32
and/or mingw_build_win64 on top of each spec file:
%global mingw_build_win32 1
%global mingw_build_win64 1
This commit changes it so that the default is now defined in system-wide
macros and each individual package doesn't have to clutter their spec
files with these two lines. The default is to build both 32 bit and 64
bit packages; if spec files need to opt out, they can just define either
mingw_build_win32 or mingw_build_win64 to 0.
Commit f3b87dde removed a needed 'shift' from mingw-find-debuginfo.sh,
which made debuginfo generation often complain about directories not
found.
Add the 'shift' back and at the same time improve argument parsing error
messages.
- Fixed rpmlint issues
- Fixed permissions of the scripts (775 -> 755)
- Fixed description of the various subpackages
- Make the various macros compliant with the new packaging guidelines:
https://fedorahosted.org/fpc/ticket/71
- Suppress arch-independent-package-contains-binary-or-object rpmlint
errors for static libraries
- Improved the mingw_configure, mingw_make, mingw_make_install,
mingw_cmake and mingw_cmake_kde4 RPM macros so packagers don't need
to use quotes anymore when using arguments. Thanks to Kalev Lember
for the initial proof of concept
- Dropped the -mms-bitfields argument from the default CFLAGS as
it is enabled by default as of gcc 4.7
- Replaced the CMake defines QT_HEADERS_DIR and QT_LIBRARY_DIR
with QT_BINARY_DIR which is a more proper method to make CMake
aware of the location of Qt. Thx to Dominik Schmidt for the hint
- Make sure CMake can detect the qmake-qt4 binary in /usr/$target/bin
- Make sure CMake can also detect the (native) Qt tools
qdbuscpp2xml and qdbusxml2cpp
- Added new RPM macros mingw_cmake_kde4, mingw32_cmake_kde4 and
mingw64_cmake_kde4
- Added three new environment variables which can be set to
influence the behaviour of the cmake macros:
MINGW_CMAKE_ARGS, MINGW32_CMAKE_ARGS and MINGW64_CMAKE_ARGS
- Dropped the mingw32-qmake-qt4 and mingw64-qmake-qt4 wrapper scripts
as they're now provided by the mingw{32,64}-qt-qmake packages
- Added a new RPM macro: %%{?mingw_package_header}
Packagers can use this macro instead of the original boilerplate
code which is needed for all mingw packages
- Made argument passing using the backwards compatibility macro
%%{_mingw32_cmake} work
- Fixed an issue in the mingw_cmake macro where it could point to
a non-existant CMakeLists.txt file
- Fixed a bug in the find-requires script which causes all packages to
depend
on both the mingw32 and the mingw64 toolchains
- Split out the RPM macros which require both the
mingw{32,64}-filesystem
packages in a new file and put it in the mingw-filesystem-base package
- Generate seperate debuginfo packages for mingw32 and mingw64
- Set the minimum version of R: mingw{32,64}-filesystem to 70
- Use the correct FSF-address in some scripts
- Thanks to all the contributors: Erik van Pienbroek, Kalev Lember,
Levente
Farkas, Marc-Andre Lureau.
The -n option was passed down to -debuginfo subpackage's %package and
%description sections, but not to %files. This change fixes %files to
work the %same way as %package and %description.
Not sure yet if the -n option will get any use, but at least this fixes
an obvious oversight.
https://bugzilla.redhat.com/show_bug.cgi?id=700815#c12
The automatically generated Requires were too strict, making every
binary rpm depend on the very latest mingw32-filesystem. For almost all
packages any mingw32-filesystem from Fedora repos is sufficient.
Using versionless mingw32-filesystem Requires avoids the situation where
e.g. downgrading mingw32-filesystem would be impossible due to other
packages needlessly depending on it.
