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 _______________________________________________ mingw mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/mingw
