[CMake] Mixed linking

2015-02-06 Thread Ray Donnelly
Hi, Apologies that this won't tread correctly (and for directly CC'ing the three participants); I only signed up to the mailing list after I saw this conversation. I'm an MSYS2 developer (and I occasionally hack on Qt build system issues). I've spent a lot of time working on our qt5 and

Re: [CMake] Mixed linking

2015-02-06 Thread Norbert Pfeiler
Norbert Pfeiler wrote: Currently you have to define »QT_STATIC« You shouldn't need to do this. If you use MSYS2's mingw-w64-{i686,x86_64}-qt5-static then that will be defined for you. I have both *-qt5 (for dev) and *-qt5-static (for deploy) installed and append the root of qt5-static to

[CMake] CMP0026 - Disallow use of the LOCATION target property

2015-02-06 Thread Jifeng ZHANG
Hi, I have a question of policy CMP0026. Our project currently is on CMake 2 and we are planning to move to CMake 3. When we run CMake3.1.1, we get get a few warnings due to the policy CMP0026, Disallow use of the LOCATION target property. Even though with those warnings, our cmake scripts still

Re: [CMake] ExternalProject_add and add_subdirectory in one step

2015-02-06 Thread Petr Kmoch
Hi Franz. The canonical approach to ExternalProject is to use a superbuild setup. Design your top-level CMakeList so that it *only* contains ExternalProject_add() calls, treating your original project as just another external project. Build the superbuild once, getting all the dependencies

[CMake] Modern CMake with Qt5 and packaging on OS X

2015-02-06 Thread Michael Jackson
We are migrating our application from Qt4 to Qt5. In the past we had a combination of a cmake script and shell script that would fix-up the application bundle on OS X. This does not seem to work any more in that we are missing the platform plugins and a few other items. Are there any examples

Re: [CMake] Mixed linking

2015-02-06 Thread Norbert Pfeiler
But I just don't know how to include the plugins. Actually, I always get the error about the platform plugin (cocoa in my case). Any tips ? For Windows it’s like this: #if defined(Q_OS_WIN) defined(QT_STATIC) #include QtPlugin Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin) #endif Best,

Re: [CMake] Mixed linking

2015-02-06 Thread Ghyslain Leclerc
Hello again. Thanks for the answers. To Stephen Kelly: Here are a few questions for the list (hoping someone more knowledgable than me will read this and help): 1) Am I right when I say CMake, Qt and static linking don?t mix ? They should mix fine. Alright, I won't give up just yet. :-)

Re: [CMake] Modern CMake with Qt5 and packaging on OS X

2015-02-06 Thread Bill Somerville
On 06/02/2015 14:00, Michael Jackson wrote: Hi Mike, We are migrating our application from Qt4 to Qt5. In the past we had a combination of a cmake script and shell script that would fix-up the application bundle on OS X. This does not seem to work any more in that we are missing the platform

Re: [CMake] CMP0026 - Disallow use of the LOCATION target property

2015-02-06 Thread Stephen Kelly
Jifeng ZHANG wrote: Hi, I have a question of policy CMP0026. Our project currently is on CMake 2 and we are planning to move to CMake 3. Lot's of questions on that lately. Someone opened the floodgates it seems :). When we run CMake3.1.1, we get get a few warnings due to the policy

Re: [CMake] Mixed linking

2015-02-06 Thread Stephen Kelly
Norbert Pfeiler wrote: But I just don't know how to include the plugins. Actually, I always get the error about the platform plugin (cocoa in my case). Any tips ? For Windows it’s like this: #if defined(Q_OS_WIN) defined(QT_STATIC) #include QtPlugin

Re: [cmake-developers] FindRuby doesn't find 64-bit Ruby on Windows

2015-02-06 Thread Brad King
On 02/06/2015 03:29 PM, Michael Smith wrote: The 64-bit ruby library names are: * lib/libx64-mscvrt-ruby210-static.a * lib/libx64-mscvrt-ruby210.dll.a * bin/x64-mscvrt-ruby210.dll I've attached a patch that adds x64- prefixed lookup Thanks for working on this. Some of the other find

[cmake-developers] FindRuby doesn't find 64-bit Ruby on Windows

2015-02-06 Thread Michael Smith
It appears FindRuby fails to find 64-bit Ruby on Windows. Debug output is -- FindRuby.cmake debug -- _RUBY_POSSIBLE_EXECUTABLE_NAMES: ruby1.9;ruby19;ruby;ruby2.1;ruby21;ruby2.0;ruby20;ruby1.8;ruby18 -- _RUBY_POSSIBLE_LIB_NAMES:

[Cmake-commits] CMake branch, next, updated. v3.1.2-1112-g57d15db

2015-02-06 Thread Brad King
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 57d15db5af7074d421ee5f86eafcf852c93e2d6a (commit) via

Re: [cmake-developers] FindRuby doesn't find 64-bit Ruby on Windows

2015-02-06 Thread Michael Smith
Non-prefixed names shouldn't be used for 64-bit architectures. The only major releases with 64-bit support are 2.0.0 and 2.1.5, and both use the x64- prefix. New patch attached. Follow-up question: Why doesn't FindRuby use Config::CONFIG['LIBRUBY'], 'LIBRUBY_A', 'LIBRUBY_SO' to search for libs?

[Cmake-commits] CMake branch, master, updated. v3.1.2-1020-g8b7e5e5

2015-02-06 Thread Kitware Robot
20150206) +set(CMake_VERSION_PATCH 20150207) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake

Re: [cmake-developers] FindRuby doesn't find 64-bit Ruby on Windows

2015-02-06 Thread Ben Boeckel
On Fri, Feb 06, 2015 at 15:00:50 -0800, Michael Smith wrote: Non-prefixed names shouldn't be used for 64-bit architectures. The only major releases with 64-bit support are 2.0.0 and 2.1.5, and both use the x64- prefix. New patch attached. What about AArch64? Follow-up question: Why doesn't

Re: [cmake-developers] FindRuby doesn't find 64-bit Ruby on Windows

2015-02-06 Thread Michael Smith
On Fri, Feb 6, 2015 at 4:42 PM, Ben Boeckel ben.boec...@kitware.com wrote: On Fri, Feb 06, 2015 at 15:00:50 -0800, Michael Smith wrote: Non-prefixed names shouldn't be used for 64-bit architectures. The only major releases with 64-bit support are 2.0.0 and 2.1.5, and both use the x64-

[Cmake-commits] CMake branch, next, updated. v3.1.2-1072-gabee514

2015-02-06 Thread Brad King
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via abee514ddbf3a5b3fb5fea1a4b755149100eaf5d (commit) via

Re: [cmake-developers] msbuild VisualStudioEdition value (was: Fix for Windows Store warning APPX1901...)

2015-02-06 Thread Robert Goulet
Gilles? Any advices about this one? Thanks! -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Tuesday, February 3, 2015 3:12 PM To: Robert Goulet; Gilles Khouzam Cc: cmake-developers@cmake.org Subject: Re: msbuild VisualStudioEdition value (was: Fix for Windows

Re: [cmake-developers] Fortran detection, issue 9220

2015-02-06 Thread Ben Boeckel
On Fri, Feb 06, 2015 at 07:01:55 +0100, Christoph Grüninger wrote: would you mind to tackle issue 9220 enable_language( OPTIONAL) signature does not work correctly? It's a shame that CMake cannot properly detect optional Fortran for more than 5 years! The workaround from Eigen works fine

[Cmake-commits] CMake branch, next, updated. v3.1.2-1094-ged2953e

2015-02-06 Thread Stephen Kelly
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via ed2953e57b017f3bbfb189658c98a34dd44d9993 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.1.2-1076-g9d3b0df

2015-02-06 Thread Brad King
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 9d3b0dfd93694ffee04c5b4b5795aa7ebf6ca059 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.1.2-1099-gc9827da

2015-02-06 Thread Stephen Kelly
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via c9827dabebf5d3e93d2f37223141f2ccd5209b1a (commit) via

[Cmake-commits] CMake branch, next, updated. v3.1.2-1101-g3aea927

2015-02-06 Thread Stephen Kelly
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 3aea9271e7d727191e862f67cb29341334a73b4b (commit) via

[Cmake-commits] CMake branch, next, updated. v3.1.2-1106-ga56d580

2015-02-06 Thread Stephen Kelly
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via a56d580574e11b13a9adb8de0632c6c0b4a8a4da (commit) via

[cmake-developers] GCC5 and C++11 ABI

2015-02-06 Thread Ben Boeckel
Looks like compiler_feature_detection will need to normalize the _GLIBCXX_USE_CXX11_ABI preprocessor define as well: http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

[Cmake-commits] CMake branch, next, updated. v3.1.2-1110-gac06e3e

2015-02-06 Thread Brad King
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via ac06e3ebdab8cdec3195464774bf91f9404929a4 (commit) via