Package Details: mingw-w64-cmake 1-42

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-2.0-or-later
Submitter: brcha
Maintainer: xantares
Last Packager: xantares
Votes: 58
Popularity: 0.052455
First Submitted: 2013-04-17 12:11 (UTC)
Last Updated: 2025-09-01 16:36 (UTC)

Latest Comments

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

Martchus commented on 2025-09-01 20:57 (UTC)

Thanks!

xantares commented on 2025-09-01 16:36 (UTC)

hi, yes done

Martchus commented on 2025-08-30 10:22 (UTC) (edited on 2025-08-30 10:24 (UTC) by Martchus)

Hi, could you apply the following changes?

Denzy7 commented on 2024-10-23 10:59 (UTC) (edited on 2024-10-23 11:02 (UTC) by Denzy7)

@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

Martchus commented on 2024-10-18 08:50 (UTC)

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

Denzy7 commented on 2024-10-18 06:47 (UTC)

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}")
]])

mrpinkolik commented on 2023-01-31 10:14 (UTC)

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

class101 commented on 2022-01-01 02:30 (UTC) (edited on 2022-01-01 02:33 (UTC) by class101)

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 (UTC)

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 (UTC) (edited on 2021-10-31 17:27 (UTC) by Martchus)

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

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