Package Details: mingw-w64-cmake 1-40

Git Clone URL: https://aur.archlinux.org/mingw-w64-cmake.git (read-only, click to copy)
Package Base: mingw-w64-cmake
Description: CMake wrapper for MinGW (mingw-w64)
Upstream URL: http://fedoraproject.org/wiki/MinGW
Licenses: GPL
Submitter: brcha
Maintainer: xantares
Last Packager: xantares
Votes: 57
Popularity: 0.44
First Submitted: 2013-04-17 12:11 (UTC)
Last Updated: 2022-12-05 17:39 (UTC)

Latest Comments

« First ‹ Previous 1 .. 4 5 6 7 8 9

xantares commented on 2015-12-08 13:07 (UTC)

@cloudef - Native flags from makepkg should not be read, the option !buildflags should be set in every mingw package, as you may have something like march=... which is invalid for cross-compiling I'm no expert in what those flags are and what they should be, I wanted to standardize the way mingw packages are built (see also mingw-w64-configure). I just took them from Fedora, and maybe they even changed. - I may have put them here because I had several packages relying on this behavior. I also use the toolchain files for development, and setting these variables in the toolchain would maybe be more annoying than the cmake unused warning. xan.

Cloudef commented on 2015-12-07 13:50 (UTC)

@xantares I usually expect packages on arch / aur to be close to upstream / vanilla as possible so the CFLAGS and BUILD_SHARED_LIBS came as bit of surprise. For example the CFLAGS looks quite similar to that of /etc/makepkg.conf default ones, but cmake _does_ read CFLAGS and CXXFLAGS first time cmake is ran, so it will actually work with /etc/makepkg.conf and you don't have to set them in the script, to avoid surprises for some. The fexceptions also makes no sense in the flags. nor the ssp buffer size without enabling ssp. -Wp, (while correct) is unneccessary. Also they set some defaults like -O2 with -g, this is all quite undesirable for people who simply assume it just handles cross-compilation using mingw but doesn't touch anything else. For BUILD_SHARED_LIBS, while I agree there are many horrible cmake projects and they do weird things regarding this global variable, or weird things in general. I think these hacks should be handled at their respective PKGBUILDs. CMAKE_INSTALL_LIBDIR INCLUDE_INSTALL_DIR LIB_INSTALL_DIR SHARE_INSTALL_DIR SYSCONF_INSTALL_DIR These variables also aren't standard CMake variables, apart from CMAKE_INSTALL_LIBDIR, that is actually provided by GNUInstallDirs cmake module. Others are hacks by project developers who dint bother reading CMake documentation and find about GNUInstallDirs, or the project was done with very early before GNUInstallDirs was available. While it's bit dirty, I don't propose removal of those variables. But you might be able to put them into toolchain file instead and avoid CMake warning about unused manually specified variables. I think this package is highly useful and really nice, but these 2 certainly were surprising to me. Especially since I actually used this in development instead of building AUR packages.

xantares commented on 2015-12-07 12:38 (UTC)

@cloudef: - these are CFLAGS that go well for mingw, I dont know the meaning of all flags, but you need at least to override native flags that would be invalid here - BUILD_SHARED_LIBS is set to build shared libs by default, but not every packages honor this canonical way of deciding static/shared, some use another name or set the default value to OFF

Cloudef commented on 2015-12-07 09:46 (UTC)

Why do you specify CFLAGS and force BUILD_SHARED_LIBS in the wrapper?

Schala commented on 2013-05-08 21:49 (UTC)

Oooh I didn't see that.

brcha commented on 2013-04-17 15:28 (UTC)

Why? What's the difference? The names are symlinked. I can make the scripts be *-w64-mingw32-cmake and symlinks mingw{32,64}-cmake, but I see no difference between the two combinations.

Schala commented on 2013-04-17 15:25 (UTC)

Could you rename the wrapper scripts to (i686/x86_64)-w64-mingw32? It helps. Thanks

« First ‹ Previous 1 .. 4 5 6 7 8 9