Hi all,
This is a heads up to announce a new version of the mingw-filesystem
package. As of version 100 of this package many improvements were
applied, especially regarding CMake support. Here's an overview:
CMAKE_SYSTEM_PROCESSOR
----------------------
The CMake variable CMAKE_SYSTEM_PROCESSOR has been added to the CMake
toolchain files. According to
http://www.vtk.org/Wiki/CMake_Cross_Compiling this CMake variable
should be part of the toolchain files so we added it there. This
variable is used for example by recent webkitgtk versions to find out
the system architecture (x86 or x86_64).
Optional verbose make
---------------------
When using one of the CMake RPM macros (like %mingw32_cmake) or one of
the CMake wrapper scripts (like /usr/bin/mingw32-cmake) you probably
have noticed that the output of the 'make' command was always verbose.
As of this version of mingw-filesystem this behavior has changed: The
CMake RPM macros still use verbose make by default, but when using the
CMake wrapper scripts verbose make won't be used by default.
If you're using the CMake wrapper scripts and still want to use
verbose make then there are two ways to achieve this:
1. By using "/usr/bin/mingw32-cmake -DCMAKE_VERBOSE_MAKEFILE=ON"
2. By using "make VERBOSE=1"
See also:
https://bugzilla.redhat.com/show_bug.cgi?id=987644
CMAKE_BUILD_TYPE support
------------------------
CMake provides a capability to use a different subset of compiler
flags based on the contents of a variable called CMAKE_BUILD_TYPE.
This can be used to create 'Debug', 'Release', 'RelWithDebInfo' or
'MinSizeRel' builds. In the past the contents of this variable were
ignored and the default Fedora MinGW compiler flags were automatically
used.
When using the CMake wrapper scripts the default Fedora MinGW compiler
flags aren't used any more which should allow CMAKE_BUILD_TYPE to work
as expected. The behavior of the CMake RPM macros has not changed.
See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1136069
CPack support
-------------
With CPack it is possible to easily generate (NSIS) installers from
compiled CMake projects. In the past an error message was shown when
trying to use this feature. Using CPack should work fine now with the
latest mingw-filesystem.
This was resolved by removing the LIB_INSTALL_DIR variable from the
CMake toolchain files. A test was done against all Fedora MinGW CMake-
based packages and no breakage was encountered with this variable
removed.
See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1152696
Toolchain file renamed
----------------------
Previously the CMake toolchain files were stored in
/usr/share/mingw/Toolchain-mingw32.cmake and
/usr/share/mingw/Toolchain-mingw64.cmake. As file names on Linux are
normally all lowercase we've renamed these files to
/usr/share/mingw/toolchain-mingw32.cmake and
/usr/share/mingw/toolchain-mingw64.cmake
This should only affect users which were calling /usr/bin/cmake
directly instead of using the MinGW CMake wrapper scripts
CMake rpath
-----------
When using the CMake RPM macros or the CMake wrapper scripts a CMake
flag was automatically used to enable rpath support. As win32/win64
don't have rpath support this CMake flag won't be used by default any
more.
Removed Boost_COMPILER
----------------------
Older versions of mingw-filesystem had the variable Boost_COMPILER set
in the CMake toolchain files. The value of this variable was incorrect
for quite some time (it still pointed to gcc 4.7) and no breakage was
detected in the past years so it was dropped.
Empty MINGW{32,64}_{C,CPP,CXX}FLAGS environment variables
---------------------------------------------------------
When using the MinGW RPM macros or the various wrapper scripts it was
already possibly to override the default compiler flags by setting one
or more environment variables. Testing has shown that these
environment variables weren't respected when they were set to an empty
value. As of this version of mingw-filesystem it is now possible to
supply an empty set of compiler flags (which also prevents the default
compiler flags from being used)
Removed deprecated _mingw32 RPM macros
--------------------------------------
As of Fedora 17 (June 2012) support for win64 became available. Due to
this a large part of the already available mingw32 RPM macros was
rewritten and the old mingw32 RPM macros (like %_mingw32_configure)
were marked as deprecated and shouldn't have been used any more in
packages. These deprecated RPM macros have now been removed from the
latest mingw-filesystem.
The RPM macros mentioned in the Fedora MinGW packaging guidelines at
https://fedoraproject.org/wiki/Packaging:MinGW are all still valid and
haven't been changed.
The updated mingw-filesystem is currently being pushed to all active
branches: EPEL-6, EPEL-7, F21, F22 and rawhide.
If you encounter any issues with this new version of mingw-filesystem
please let me know.
Regards,
Erik van Pienbroek