Package Details: mingw-w64-cmake 1-39

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: 52
Popularity: 0.007010
First Submitted: 2013-04-17 12:11
Last Updated: 2021-12-03 20:35

Dependencies (5)

Required by (257)

Sources (2)

Latest Comments

1 2 3 4 5 6 ... Next › Last »

class101 commented on 2022-01-01 02:30

I see that's a different usage.

In my opinion your wrapper script works great. All it needed I explained in the bottom on my previous comment, if you convert the parameters into environnement variable, the expected result will probably be what you want, and it executes what I ask him to without problems.

In my opinion it is a common practice to replace a binary by a wrapper script on Linux to inject an environnement variable, but never seen a script to inject parameters in a program

Currently I'm using a lot CLion between windows and linux, with around 6 different toolchains and each with its debug and release build directory automatically managed by clion.

Near that I have to take care one of my co worker is under visual studio

So if I can avoid hacks into what CLion does, I prefer :D

It is just like you in the IDE, I set this once at the IDE setting level and then it works for all projects

hhromic commented on 2021-10-31 18:09

Thanks @Martchus, that's indeed a very good point. We use this on a CI setup where the sources are not expected to change after configuring the build, but yes if you expect the cmake files to change at some point, then you need to make sure you are sourcing the environment like the wrapper does :+1:

Martchus commented on 2021-10-31 17:26

When following @hhromic's example, just take care to source the mingw-w64 env because otherwise linker flags will be missing. (The wrapper sources it but of course that has no effect on the subsequent plain cmake calls which may invoke a reconfiguration of your project when CMake files change.)

hhromic commented on 2021-10-31 16:59

In addition to what Martchus said, you also don't need to use the wrapper for every cmake command, just the initial invocation to configure the build. After the build is configured, you can use the real cmake binary to run further cmake commands. For example:

$ x86_64-w64-mingw32-cmake -B build -DCMAKE_BUILD_TYPE=Release ...
$ cmake --build build
$ cmake --install build

This will pick up the environment set by the wrapper to configure the build itself. This works for me very well, but maybe other cmake experts could confirm this is a suitable approach too.

Martchus commented on 2021-10-31 15:12

Just use the normal cmake command, e.g. when using Qt Creator I prefer doing all settings within the IDEs config and don't use this wrapper at all. You can still use the wrapper for initial configuration of course.

class101 commented on 2021-10-31 12:49

mingw-w64-cmake breaks --build and other commands

Hello, I wanted to bring attention that this package breaks the use of the --build command.

Issue

After installating mingw-w64-cmake and attempting to use the --build, as the following command used by CLion fails

/usr/bin/x86_64-w64-mingw32-cmake --build /home/${USER}/dev/.../cmake-build-debug-mingw --target target -- -j 6
CMake Error: Unknown argument -j
CMake Error: Run 'cmake --help' for all supported options.

or

/usr/bin/x86_64-w64-mingw32-cmake --build /home/{USER}/dev/.../cmake-build-debug-mingw
CMake Error: Unknown argument --build
CMake Error: Run 'cmake --help' for all supported options.

Root cause

It is specified in the cmake --help-full documentation that the build options should be passed as : [-- <build-tool-options>]

 Generate a Project Buildsystem
  cmake [<options>] <path-to-source>
  cmake [<options>] <path-to-existing-build>
  cmake [<options>] -S <path-to-source> -B <path-to-build>

 Build a Project
  cmake --build <dir> [<options>] [-- <build-tool-options>]

But as mingw-w64-cmake rewrite the cmake launcher, it is forcing options to be added before the --build parameter, and so on, breaks its use.

Fix

One solution would be to change

PATH=${mingw_prefix}/bin:$PATH cmake \
    -DCMAKE_INSTALL_PREFIX:PATH=${mingw_prefix} \
    -DCMAKE_INSTALL_LIBDIR:PATH=lib \
    -DCMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES:PATH=${mingw_prefix}/include \
    -DCMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES:PATH=${mingw_prefix}/include \
    -DBUILD_SHARED_LIBS:BOOL=ON \
    -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-x86_64-w64-mingw32.cmake \
    -DCMAKE_CROSSCOMPILING_EMULATOR=/usr/bin/x86_64-w64-mingw32-wine \
    "$@"

to

PATH=${mingw_prefix}/bin:$PATH cmake "$@" -- \
    -DCMAKE_INSTALL_PREFIX:PATH=${mingw_prefix} \
    -DCMAKE_INSTALL_LIBDIR:PATH=lib \
    -DCMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES:PATH=${mingw_prefix}/include \
    -DCMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES:PATH=${mingw_prefix}/include \
    -DBUILD_SHARED_LIBS:BOOL=ON \
    -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-x86_64-w64-mingw32.cmake \
    -DCMAKE_CROSSCOMPILING_EMULATOR=/usr/bin/x86_64-w64-mingw32-wine

I have checked, this works with --build now, but fails with others -_-.

So I believe to really fix this package, you will need to bring a more elegant wrapper script, or rebuild from sources to work properly with all the possible cmake use cases.

So it seem cmake is waiting for the [options] tag at different positions depending on the requested command line, this sound very difficult to make a perfect 'all-in-one' wrapper script to support everything

Maybe a cleaner way would be to pass them as environment variable, I have read in the docs that CMake is supposed to fork them

Tested on cmake 3.21.4

Edit: This seems to work better

PATH=${mingw_prefix}/bin:${PATH} \
CMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-x86_64-w64-mingw32.cmake \
CMAKE_INSTALL_PREFIX=${mingw_prefix} \
CMAKE_INSTALL_LIBDIR=lib \
CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES=${mingw_prefix}/include \
CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES=${mingw_prefix}/include \
BUILD_SHARED_LIBS=ON \
CMAKE_CROSSCOMPILING_EMULATOR=/usr/bin/x86_64-w64-mingw32-wine \
cmake "$@"

Martchus commented on 2021-08-11 12:54

@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

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

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

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).