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.68
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 .. 9 Next › Last »

Martchus commented on 2021-08-11 12:54 (UTC)

@nik123true When using static libraries there are some rough edges. Maybe this CMake find module needs indeed fixing to work with our packaging. (For using the mingw-64-qt6-*-static packages I've created https://aur.archlinux.org/packages/mingw-w64-cmake-static as some of Qt's dependencies are problematic and I needed a way to globally prefer static libs over dynamic libs. It is a very hacky approach but as a last resort you can try something similar.)

nik123true commented on 2021-08-11 11:46 (UTC)

The static version of the library (GLEW::glew_s) is not detected by FindGLEW() in CMake. This does not seem to be the case when building in Windows using MSYS2. I can't seem to track down what is causing the issue exactly. Sorry about that.

jpcima commented on 2021-05-25 01:29 (UTC) (edited on 2021-05-25 01:38 (UTC) by jpcima)

The source statement in the script does not work when /bin/sh is linked to dash. This should changed to . instead.

Edit: . is not sufficient, it is unable pass the argument to mingw-env. changing to #!/bin/bash is not a bad solution either.

Martchus commented on 2021-02-04 16:17 (UTC)

That's true. I've also realized that we'd still miss dynamically sourcing the environment variables provided by mingw-w64-environment (which supposedly instead needed to be hard-coded into the presets at build-time of this package).

xantares commented on 2021-02-04 16:09 (UTC)

It seems it would better suit per-projects configurations, not our distribution-wide settings.

Martchus commented on 2021-02-04 14:15 (UTC)

This recently added CMake-feature might be useful: https://cmake.org/cmake/help/v3.19/manual/cmake-presets.7.html

(I don't have any concrete plan to use it here. I'm just mentioning it because some people here might find it interesting.)

Martchus commented on 2021-01-31 17:55 (UTC)

When using Qt Creator I don't use any of those wrappers except maybe for initially preparing the build directory manually beforehand. Otherwise it seems easier to create a kit within the settings which has an appropriate CMake configuration (but still let it use CMake directly). It is now also possible to set initial CMake parameters directly within the build configuration.

pingplug commented on 2021-01-31 17:40 (UTC)

qt creator use cmake -E capabilities to check cmake version and file-api, -Dxxx before -E cause an error.

xantares commented on 2021-01-07 17:30 (UTC)

your patch is ok, but its probably useless to have it

jpcima commented on 2020-12-08 00:47 (UTC)

@xantares not anything that I would call a use-case, more an expectation. This lead to error in one occasion, in attempt to use it in CI setting.

is there an inconvenient to the solution proposed?

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