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: 56
Popularity: 0.000095
First Submitted: 2013-04-17 12:11 (UTC)
Last Updated: 2022-12-05 17:39 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »

<deleted-account> commented on 2020-11-24 15:32 (UTC)

yes, I just built it myself without wine.

xantares commented on 2020-11-24 15:08 (UTC)

are you sure gmp builds without wine ?

<deleted-account> commented on 2020-11-24 15:04 (UTC)

you are right, didn't look that far into the dependencies. problem fixed by removing wine from the gmp PKGBUILD.

xantares commented on 2020-11-24 14:55 (UTC)

it probably installs wine when building gmp which is a dependency of ceres

<deleted-account> commented on 2020-11-24 14:39 (UTC)

IMHO having Wine as an optional depend is totally not worth it. yay or other package managers will still try to install it when resolving dependencies, I'm having a load of trouble trying to install mingw-w64-ceres-solver and there is no way to avoid wine, which eventually fails because it can't resolve all its dependencies.

Martchus commented on 2020-11-08 15:13 (UTC) (edited on 2020-11-08 15:54 (UTC) by Martchus)

As mentioned in your PR, I patched Qt 6 and the Vulkan library problem was just due to forcing static libraries. So I suppose all that's left is actually specific to the static version. I'll create a separate package (mingw-w64-cmake-static) for that.

xantares commented on 2020-11-07 12:21 (UTC)

I dont know where to start, what are the specific issues you're talking about ?

Martchus commented on 2020-11-07 11:05 (UTC)

In order to workaround certain issues regarding Qt 6 I've been extending the toolchain file. See this commit for further details and the actual change: https://github.com/Martchus/PKGBUILDs/commit/1c6dcbd4ed4482cdb8ed24276b5d3979bcd7dcdc

However, I still need to further test the static version and there are likely further adjustments required. So this is just a heads up. If I'm done it would be great do sync this package with my version on GitHub/PKGBUILDs.

And yes, this is hacky. Maybe some of this can be improved in the future, e.g. CMakes Vulkan find module might be fixed upstream to cover our needs.

hhromic commented on 2019-12-03 16:57 (UTC)

@Martchus that sounds good to me if -O3 is not problematic :)

Our builds seems to be working fine with it so no problem from my side. Yes the binaries are larger but I guess that is the cost to pay for the optimisation. If necessary one can always override with -O2 in the CMake project itself anyway.

So if you are okay, I'm happy to report my original problem as resolved. Thanks to both for the quick help, really appreciated.

Martchus commented on 2019-12-03 14:56 (UTC) (edited on 2019-12-03 14:57 (UTC) by Martchus)

However I noticed that CMake also defaults to [...]

This is actually a change I've expected and think it is ok and even wanted for consistency with how it works when invoking CMake manually.

So your observation regarding the flags is actually not different from how regular packages work: When CMAKE_BUILD_TYPE is empty (like it is by default) only the default flags from /etc/makepkg.conf (regular packages) or mingw-w64-environment (now for mingw-w64 packages) are used. If a specific package passes -DCMAKE_BUILD_TYPE=Release, additional build flags like -O3 are appended by CMake in addition to the default flags. Note that the official regular packages usually just don't pass -DCMAKE_BUILD_TYPE=Release to stick to the default.

I don't think -O3 is problematic (not for regular packages and not for mingw-w64 packages). So I usually have -DCMAKE_BUILD_TYPE=Release in my own (regular) packages. The only disadvantage I've noticed so far is an increased binary size (likely due to more aggressive inlining).