Search Criteria
Package Details: mingw-w64-cmake 1-40
Package Actions
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.74 |
First Submitted: | 2013-04-17 12:11 (UTC) |
Last Updated: | 2022-12-05 17:39 (UTC) |
Dependencies (5)
- cmake (cmake-gitAUR)
- mingw-w64-environmentAUR (llvm-mingw-w64-environmentAUR)
- mingw-w64-gcc (mingw-w64-gcc132AUR, llvm-mingw-w64-toolchain-ucrt-binAUR, llvm-mingw-w64-toolchain-msvcrt-binAUR)
- mingw-w64-pkg-configAUR (llvm-mingw-w64-pkg-configAUR)
- mingw-w64-wineAUR (optional) – runtime support
Required by (278)
- mingw-w64-abseil-cpp (make)
- mingw-w64-agrum (make)
- mingw-w64-aom (make)
- mingw-w64-armadillo (make)
- mingw-w64-asmjit (make)
- mingw-w64-assimp (make)
- mingw-w64-async++-git (make)
- mingw-w64-avisynthplus (make)
- mingw-w64-blas (make)
- mingw-w64-blosc (make)
- mingw-w64-box2d (make)
- mingw-w64-brotli (make)
- mingw-w64-bullet (make)
- mingw-w64-c++utilities (make)
- mingw-w64-c-ares (make)
- mingw-w64-capstone (make)
- mingw-w64-catch2v3 (make)
- mingw-w64-cblas (make)
- mingw-w64-ceres-solver (make)
- mingw-w64-cfitsio (make)
- Show 258 more...
Latest Comments
« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »
Martchus commented on 2019-11-10 12:08 (UTC)
Why did you change
_FORTIFY_SOURCE=0
?hhromic commented on 2019-10-16 22:51 (UTC)
Hi again, I think I figured it out now. The variable I need to use is
CMAKE_STAGING_PREFIX
, which is used for cross-compiling environment such as this package. I tested and does exactly what I needed.Thanks anyway!
hhromic commented on 2019-10-16 21:30 (UTC)
Hi guys, First of all, thank you very much for putting together this wrapper package. Is simply amazing and makes things so easy to use!
However I'm having trouble setting
CMAKE_INSTALL_PREFIX
in my builds. When I set this variable, theCMAKE_SYSTEM_PREFIX_PATH
ends up wrong and things likefind_path()
stop working. For example:No install prefix provided, default is
/usr/x86_64-w64-mingw32
:Install prefix provided
-DCMAKE_INSTALL_PREFIX=/tmp/install
:As you can see, the system path
/usr/x86_64-w64-mingw32
is not present anymore and of coursefind_path()
doesn't find things correctly.I noticed that in other environments such as MSYS2 or standard cmake, things work as expected. For example in standard cmake in ArchLinux:
No install prefix provided, default:
/usr/local
:Install prefix provided
-DCMAKE_INSTALL_PREFIX=/tmp/install
:As you can see, the system path
/usr/local
is actually duplicated, therefore if you change the defaultCMAKE_INSTALL_PREFIX
it doesn't break.Now, I noticed that in the mingw-w64-cmake package, the wrapper
mingw-cmake.sh
actually passesCMAKE_INSTALL_PREFIX=${mingw_prefix}
and providing it externally actually overrides it. Therefore, explaining the issue.With all that, I would kindly like to ask how I'm supposed to set a custom
CMAKE_INSTALL_PREFIX
of my own with this mingw-w64-cmake package?Is this a short-coming of the wrapper? Thanks!
xantares commented on 2019-03-27 20:01 (UTC)
I just tested https://gitlab.kitware.com/cmake/cmake/merge_requests/3157, and it fixes it.
xan.
xantares commented on 2019-03-27 09:46 (UTC) (edited on 2019-03-27 10:32 (UTC) by xantares)
I'm not setting CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES myself
I think it appears only in C++ and when using a cmake config file (FooConfig.cmake used by find_package(Foo))
the problem appears with jsoncpp for example:
$ aurman -S --noconfirm --noedit mingw-w64-jsoncpp
$ git clone --depth 1 https://github.com/xantares/pkgtest.git && cd pkgtest && x86_64-w64-mingw32-cmake . && make
we can see that ./CMakeFiles/t_jsoncpp.dir/includes_CXX.rsp contains "-isystem /usr/x86_64-w64-mingw32/include"
interesting thing is that with cmake 3.13.4 the includes_CXX.rsp is not used/present
Martchus commented on 2019-03-26 20:05 (UTC)
I created an issue: https://gitlab.kitware.com/cmake/cmake/issues/19095
xantares commented on 2019-03-26 19:59 (UTC)
yeah, on simple stuff it goes fine here too.
I've got it with:
https://github.com/xantares/pkgtest
compiling t_agrum
Martchus commented on 2019-03-26 19:56 (UTC)
Do you have a simple example? I've just tried with a simple project file and couldn't reproduce it. That's currently preventing me from filing an issue.
By the way, if you're wondering why I haven't updated Qt to 5.12.2 yet - that issue delayed my tests.
xantares commented on 2019-03-26 19:47 (UTC)
yes, this is bad I've got it too.
if you do file an issue can you post its link here too so I can follow ?
Martchus commented on 2019-03-26 19:40 (UTC)
I'm going to file an issue. I reproduce this by building one of my projects, e.g. Syncthing Tray. When I downgrade the CMake version installed in the systemd container and re-run CMake it works again. So it is quite likely that a change in CMake is responsible. Someone on the #cmake channel on free node also told me that there were changes regarding implicit include directories made.
« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »