Arch Linux User Repository

@Martchus GET_RUNTIME_DEPENDENCIES is used to get shared libraries used by a target so you can copy dll's to the target install directory. This makes dll's that sth like mingw-w64-gtk3 to be easily copied since they are many.

I did notice cmake --install exits without an error on msys2 but nothing get copied over

@Denzy7 Probably nobody uses that yet in a cross mingw-w64 environment - so I guess some rough edges are expected. Not sure what GET_RUNTIME_DEPENDENCIES internally does. Maybe it depends on an external tool that is not installed or correctly selected. You'll have to debug this. Maybe I can also have a look at some point considering this might actually be a useful feature.

I have an issue using install file(GET_RUNTIME_DEPENDENCIES. It works ok with linux cmake but throws an error:

CMake Error at /tmp/mingw/cmake_install.cmake:41 (file):
  file unknown error.

cmake_minimum_required(VERSION 3.10)
project(bruhlib)
add_library(lib SHARED 
    lib.c)
set_target_properties(lib PROPERTIES
    POSITION_INDEPENDENT_CODE ON
    PREFIX ""
    SUFFIX ".bruh")
add_executable(main 
    dl.c)

cmake_policy(SET CMP0087 NEW)
install(CODE [[
    file(GET_RUNTIME_DEPENDENCIES 
        EXECUTABLES $<TARGET_FILE:main>
        LIBRARIES $<TARGET_FILE:lib>
        RESOLVED_DEPENDENCIES_VAR resol
        UNRESOLVED_DEPENDENCIES_VAR unresol
        CONFLICTING_DEPENDENCIES_PREFIX conflict
    )
    message("${resol} ${unresol} ${conflict}")
]])

@class101 That's why I love Arch. Whenever I have a problem, there's already someone who had solved it

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

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:

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

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.

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.

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 "$@"