Changes in latest mingw-filesystem

[Erik van Pienbroek]

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