[cmake-developers] [CMake 0015670]: Add support for setting "Windows target platform version" in VS2015
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15670 == Reported By:Christian Maaser Assigned To: == Project:CMake Issue ID: 15670 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2015-07-29 18:34 EDT Last Modified: 2015-07-29 18:34 EDT == Summary:Add support for setting "Windows target platform version" in VS2015 Description: The MSVS generator currently does not support setting a new property introduced with MSVS2015: The "Windows target platform version". This property effectively selects the platform SDK to use, which is independent from the selected compiler/platform toolset. Steps to Reproduce: Use "Visual Studio 14 2015 [Win64]" generator and see how tag is missing in the generated .vcxproj files Additional Information: See attached screenshot showing the new setting. Here is a subset from a regular .vcxproj file which selects the recently released Windows 10 platform SDK version. ... MultiByte v140 10.0.10240.0 ... == Issue History Date ModifiedUsername FieldChange == 2015-07-29 18:34 Christian MaaserNew Issue 2015-07-29 18:34 Christian MaaserFile Added: targetplatformversion.png == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE argument
Add a PARENT_SCOPE argument to cmake_policy(SET) that makes the policy
apply to the parent (strong) scope - it will break out of exactly one
level of the policy stack.
This is intended to be used from a "settings file" which is applied to a
group of CMake projects. This allows the file to control which policies
apply only within the file and which apply to the project. It also means
that users of the settings file are not forced to use NO_POLICY_SCOPE
(particularly important if the settings file did not originally have any
policy settings in it, but later acquired some).
---
Source/cmCMakePolicyCommand.cxx| 19 +-
Source/cmMakefile.cxx | 14 +++--
Source/cmMakefile.h| 4 +-
Tests/PolicyScope/CMakeLists.txt | 73 +-
Tests/PolicyScope/FindFoo.cmake| 1 +
Tests/PolicyScope/IncludesUsesParentScope.cmake| 1 +
.../IncludesUsesParentScopeWithCMP0011New.cmake| 2 +
.../IncludesUsesParentScopeWithCMP0011Old.cmake| 2 +
Tests/PolicyScope/UsesParentScope.cmake| 3 +
9 files changed, 109 insertions(+), 10 deletions(-)
create mode 100644 Tests/PolicyScope/IncludesUsesParentScope.cmake
create mode 100644
Tests/PolicyScope/IncludesUsesParentScopeWithCMP0011New.cmake
create mode 100644
Tests/PolicyScope/IncludesUsesParentScopeWithCMP0011Old.cmake
create mode 100644 Tests/PolicyScope/UsesParentScope.cmake
diff --git a/Source/cmCMakePolicyCommand.cxx b/Source/cmCMakePolicyCommand.cxx
index 3ef6d35..5e249a5 100644
--- a/Source/cmCMakePolicyCommand.cxx
+++ b/Source/cmCMakePolicyCommand.cxx
@@ -65,9 +65,9 @@ bool cmCMakePolicyCommand
//
bool cmCMakePolicyCommand::HandleSetMode(std::vector const& args)
{
- if(args.size() != 3)
+ if(args.size() != 3 && args.size() != 4)
{
-this->SetError("SET must be given exactly 2 additional arguments.");
+this->SetError("SET must be given 2-3 additional arguments.");
return false;
}
@@ -88,7 +88,20 @@ bool
cmCMakePolicyCommand::HandleSetMode(std::vector const& args)
return false;
}
- if(!this->Makefile->SetPolicy(args[1].c_str(), status))
+ bool include_parent = false;
+ if(args.size() == 4)
+{
+include_parent = true;
+if (args[3] != "PARENT_SCOPE")
+ {
+ std::ostringstream e;
+ e << "SET given unexpected third argument \"" << args[3] << "\"";
+ this->SetError(e.str());
+ return false;
+ }
+}
+
+ if(!this->Makefile->SetPolicy(args[1].c_str(), status, include_parent))
{
this->SetError("SET failed to set policy.");
return false;
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 57e33df..3859938 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -4791,7 +4791,8 @@ bool cmMakefile::PolicyOptionalWarningEnabled(std::string
const& var)
}
bool cmMakefile::SetPolicy(const char *id,
- cmPolicies::PolicyStatus status)
+ cmPolicies::PolicyStatus status,
+ bool include_parent)
{
cmPolicies::PolicyID pid;
if (!cmPolicies::GetPolicyID(id, /* out */ pid))
@@ -4801,12 +4802,13 @@ bool cmMakefile::SetPolicy(const char *id,
this->IssueMessage(cmake::FATAL_ERROR, e.str());
return false;
}
- return this->SetPolicy(pid,status);
+ return this->SetPolicy(pid,status,include_parent);
}
//
bool cmMakefile::SetPolicy(cmPolicies::PolicyID id,
- cmPolicies::PolicyStatus status)
+ cmPolicies::PolicyStatus status,
+ bool include_parent)
{
// A REQUIRED_ALWAYS policy may be set only to NEW.
if(status != cmPolicies::NEW &&
@@ -4822,9 +4824,13 @@ bool cmMakefile::SetPolicy(cmPolicies::PolicyID id,
// Update the policy stack from the top to the top-most strong entry.
bool previous_was_weak = true;
for(PolicyStackType::reverse_iterator psi = this->PolicyStack.rbegin();
- previous_was_weak && psi != this->PolicyStack.rend(); ++psi)
+ (previous_was_weak || include_parent) && psi !=
this->PolicyStack.rend(); ++psi)
{
psi->Set(id, status);
+if (!previous_was_weak)
+ {
+ include_parent = false;
+ }
previous_was_weak = psi->Weak;
}
diff --git a/Source/cmMakefile.h b/Source/cmMakefile.h
index 7938fcc..44a47f5 100644
--- a/Source/cmMakefile.h
+++ b/Source/cmMakefile.h
@@ -318,8 +318,8 @@ public:
/**
* Set, Push, Pop policy values for CMake.
*/
- bool SetPolicy(cmPolicies::PolicyID id, cmPolicies::PolicyStatus status);
- bool SetPolicy(const char *id, cmPolicies::PolicyStatus status);
+ bool SetPolicy(cmPolicies::PolicyID id, cmPolicies::PolicyStatus status,
bool include_parent = false);
+ bool SetPo
Re: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation
On Wednesday, July 29, 2015 04:59:57 PM Pascal Bach wrote: > Hi Clint > > Am 29.07.2015 um 16:47 schrieb Clinton Stimpson: > > On Wednesday, July 29, 2015 04:05:41 PM Pascal Bach wrote: > >> Hi Clint > >> > >> Am 29.07.2015 um 15:45 schrieb Clinton Stimpson: > >>> Hi Pascal, > >>> > >>> Thanks for the patches. > >>> > >>> Can you share with us why setting CMAKE_FIND_ROOT_PATH does not work, or > >>> how this new method compares? > >>> > >>> For example, in the toolchain file: > >>> SET(CMAKE_FIND_ROOT_PATH /path/to/Qt ...) > >> > >> The problem is how FindQt4 does find the locations using qmake. > >> > >> let's assume there are two sysroots one is /sysroots/x86_64 which > >> contains > >> binaries usable on the host machine, and there is /sysroots/arm which > >> contains libraries for the target system. this are both set via: > >> set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64) > >> set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY ) > >> set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY ) > >> set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY ) > >> set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY ) > > > > Yes, this concern of 2 sysroots has been brought up before. Thanks for > > addressing this. > > > >> Here is what happens when only setting CMAKE_FIND_ROOT_PATH: > >> > >> 1. FindQt4 is trying to find the qmake executable. As there is no qmake > >> in > >> /sysroots/arm (it would not be runnable on the host) it will find qmake > >> from the /sysroots/x86_64 directory. 2. FindQt4 is asking qmake for the > >> path to the Qt installation. As the qmake found is the one from > >> /sysroots/x86_64 it will point to the libraries from /sysroots/x86_64 > >> which > >> will obviously not run on arm! > >> > >> Currently I didn't find a way to override this behaviour of FindQt4, > >> except > >> by setting all the variables usually set by FindQt4 manually. It is > >> usually > >> accepted to set some variables manually when doing cross compilation. > >> With > >> this patchset I tried to reduce this variable to a minumum and let > >> FindQt4 > >> figure out the rest. > >> > >> The minimum variables required with the patch are: > >> > >> QT_BINARY_DIR is necessary to find the correct qmake > >> QT_LIBRARY_DIR is necessary to find the library directory > >> QT_INCLUDE_DIR is necessary to find the include directory (might be > >> possible to figure this out from QT_INCLUDE_DIR if some assumptions are > >> made) QT_MKSPECS_DIR necessary to have the correct prefixes (E in the > >> case of qt4-embedded). > >> > >> > >> I hope my explanation is clear. If there is a better way to achive this > >> I'm > >> all ears. > > > > I'm fine with this, and don't think it'll conflict with any other use > > cases. > I don't see a conflict either. > > > However, I do think we should first document setting CMAKE_FIND_ROOT_PATH, > > then afterwards document the other variables for those users which need > > more control. Does that sound reasonable? > > I'm not sure I understand what you mean. > I think how to set CMAKE_FIND_ROOT_PATH is already documented in cmake. > Are you suggesting extending the docuemntation of FindQt4below with a > paragraph documenting how to work with two sysroots? With an example like > this? > > set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64) > set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY ) What I want to avoid is users thinking that what you are proposing overrides any other way of finding Qt when cross compiling. The wording you propose is "To find Qt in a cross compile environment set the following variables" However there are users for which setting only CMAKE_FIND_ROOT_PATH is enough. Or setting CMAKE_FIND_ROOT_PATH plus QT_QMAKE_EXECUTABLE is enough. Brad had a good question in another email. Can't you set QT_QMAKE_EXECUTABLE? My guess, is no, because that qmake returns paths under one sysroot. I just realized something. Your use case is similar or the same to one I had tested FindQt4 with. Your Qt appears to be prefixed under /sysroot/arm/usr, not /sysroot/arm. Can you include /sysroot/arm/usr in CMAKE_FIND_ROOT_PATH, then see if FindQt4 can find your libraries under /sysroot/arm/usr. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modules/GetPrequisites.cmake issues
On 29/07/2015 14:37, Brad King wrote:
Hi Brad,
On 07/28/2015 06:02 PM, Bill Somerville wrote:
attached is a patch that addresses some issues recently discussed on the
users list.
...
If you're comfortable enough with Git, please split this part out into
a preceding patch with its own explanation in its commit message. That
will clarify which hunks in the patch belong to which change.
...
This can be simplified as:
execute_process(
COMMAND ${gp_cmd} ${gp_cmd_args} ${target}
${gp_cmd_maybe_filter}
RESULT_VARIABLE gp_rv
OUTPUT_VARIABLE gp_cmd_ov
ERROR_VARIABLE gp_ev
)
where ``gp_cmd_maybe_filter`` is initialized to empty and later
possibly set as:
if(gp_grep_cmd)
set(gp_cmd_maybe_filter
COMMAND ${gp_grep_cmd} "^[[:blank:]]*DLL Name: "
)
endif()
Revised patches attached.
Thanks,
-Brad
Regards
Bill Somerville.
>From 0332d20411f62d865b5a84d8e0f78f68a49d1a0b Mon Sep 17 00:00:00 2001
From: Bill Somerville
Date: Wed, 29 Jul 2015 17:05:51 +0100
Subject: [PATCH 1/2] Add error checks for execute_process() calls
Return status checks added to external command invocations so that
they do not fail silently producing incomplete install packages.
---
Modules/GetPrerequisites.cmake | 30 ++
1 file changed, 30 insertions(+)
diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake
index 23d486e..a359d2c 100644
--- a/Modules/GetPrerequisites.cmake
+++ b/Modules/GetPrerequisites.cmake
@@ -229,9 +229,14 @@ function(is_file_executable file result_var)
if(file_cmd)
execute_process(COMMAND "${file_cmd}" "${file_full}"
+RESULT_VARIABLE file_rv
OUTPUT_VARIABLE file_ov
+ERROR_VARIABLE file_ev
OUTPUT_STRIP_TRAILING_WHITESPACE
)
+ if(NOT file_rv STREQUAL "0")
+message(FATAL_ERROR "${file_cmd} failed: ${file_rv}\n${file_ev}")
+ endif()
# Replace the name of the file in the output with a placeholder token
# (the string " _file_full_ ") so that just in case the path name of
@@ -543,11 +548,21 @@ function(gp_resolved_file_type original_file file exepath
dirs type_var)
if(CYGPATH_EXECUTABLE)
execute_process(COMMAND ${CYGPATH_EXECUTABLE} -W
+ RESULT_VARIABLE env_rv
OUTPUT_VARIABLE env_windir
+ ERROR_VARIABLE env_ev
OUTPUT_STRIP_TRAILING_WHITESPACE)
+ if(NOT env_rv STREQUAL "0")
+message(FATAL_ERROR "${CYGPATH_EXECUTABLE} -W failed:
${env_rv}\n${env_ev}")
+ endif()
execute_process(COMMAND ${CYGPATH_EXECUTABLE} -S
+ RESULT_VARIABLE env_rv
OUTPUT_VARIABLE env_sysdir
+ ERROR_VARIABLE env_ev
OUTPUT_STRIP_TRAILING_WHITESPACE)
+ if(NOT env_rv STREQUAL "0")
+message(FATAL_ERROR "${CYGPATH_EXECUTABLE} -S failed:
${env_rv}\n${env_ev}")
+ endif()
string(TOLOWER "${env_windir}" windir)
string(TOLOWER "${env_sysdir}" sysroot)
@@ -765,8 +780,18 @@ function(get_prerequisites target prerequisites_var
exclude_system recurse exepa
#
execute_process(
COMMAND ${gp_cmd} ${gp_cmd_args} ${target}
+RESULT_VARIABLE gp_rv
OUTPUT_VARIABLE gp_cmd_ov
+ERROR_VARIABLE gp_ev
)
+ if(NOT gp_rv STREQUAL "0")
+if(gp_tool STREQUAL "dumpbin")
+ # dumpbin error messages seem to go to stdout
+ message(FATAL_ERROR "${gp_cmd} failed: ${gp_rv}\n${gp_ev}\n${gp_cmd_ov}")
+else()
+ message(FATAL_ERROR "${gp_cmd} failed: ${gp_rv}\n${gp_ev}")
+endif()
+ endif()
if(gp_tool STREQUAL "ldd")
set(ENV{LD_LIBRARY_PATH} "${old_ld_env}")
@@ -791,8 +816,13 @@ function(get_prerequisites target prerequisites_var
exclude_system recurse exepa
if(gp_tool STREQUAL "otool")
execute_process(
COMMAND otool -D ${target}
+ RESULT_VARIABLE otool_rv
OUTPUT_VARIABLE gp_install_id_ov
+ ERROR_VARIABLE otool_ev
)
+if(NOT otool_rv STREQUAL "0")
+ message(FATAL_ERROR "otool -D failed: ${otool_rv}\n${otool_ev}")
+endif()
# second line is install name
string(REGEX REPLACE ".*:\n" "" gp_install_id "${gp_install_id_ov}")
if(gp_install_id)
--
1.9.5.msysgit.0
>From 85c1785af125f18581e69b492409339d074ec18e Mon Sep 17 00:00:00 2001
From: Bill Somerville
Date: Wed, 29 Jul 2015 17:36:38 +0100
Subject: [PATCH 2/2] Optional filter for dependency walker & use it for
objdump on MinGW
As dumpbin.exe is no longer reliable for gcc libraries on MinGW
because it crashes on many common libraries like libgcc_s and
libgfortran it is now necessary too resort to using objdump for DLL
dependency walking. Using objdump has a secondary problem in that it
generates a lot of output for large libraries and causes
fixup_b
Re: [cmake-developers] Modules/GetPrequisites.cmake issues
On 29/07/2015 16:07, Bill Hoffman wrote: Hi Bill, On 7/29/2015 10:17 AM, Bill Somerville wrote: Is there a reason not to look for objdump before dumpbin? I was under the impression that dumpbin was selected first for non-MinGW Windows builds, I have no idea if objdump works with binaries produced by compilers other than GNU/CLang. This is why I commented about detecting MinGW, there are mentions of a MINGW CMake system variable but it doesn't seem to exist. Yes, that is the problem. This is a standalone script that is run at install time, so it does not have any information about the build toolchain. In retrospect it should have been passed more information about the build tool chain that was used. This is what we want: #dumpbin (Windows) #objdump (MinGW on Windows) #ldd (Linux/Unix) #otool (Mac OSX) There is already a documented override by setting the gp_tool variable, that's what we do in our project since we only support MinGW on Windows (at the moment). Trouble is dumpbin and objdump might both be in the PATH on Windows. You don't really know which one to use. I wonder if you found both if you could call something on each of them with one of the binaries, if you could figure out what tool would work better with it. You can't decide based on one executable since dumpbin works on some and not others, I believe the problem is with DLLs that export exactly zero symbols which is true of the GCC support libraries. It may be that if objdump is available it can always be used but I don't know that for sure, also it is still slower than dumpbin even with the patch I am proposing. -Bill Regards Bill Somerville. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation
On 07/29/2015 10:59 AM, Pascal Bach wrote: > set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64) > set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY ) If this is not sufficient to convince FindQt4 to find the right qmake and libraries then FindQt4 should be fixed to do so rather than asking the user to set more package-specific variables. > QT_BINARY_DIR is necessary to find the correct qmake If the user knows this information then s/he might as well just set QT_QMAKE_EXECUTABLE directly. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modules/GetPrequisites.cmake issues
On 7/29/2015 10:17 AM, Bill Somerville wrote: Is there a reason not to look for objdump before dumpbin? I was under the impression that dumpbin was selected first for non-MinGW Windows builds, I have no idea if objdump works with binaries produced by compilers other than GNU/CLang. This is why I commented about detecting MinGW, there are mentions of a MINGW CMake system variable but it doesn't seem to exist. Yes, that is the problem. This is a standalone script that is run at install time, so it does not have any information about the build toolchain. In retrospect it should have been passed more information about the build tool chain that was used. This is what we want: #dumpbin (Windows) #objdump (MinGW on Windows) #ldd (Linux/Unix) #otool (Mac OSX) Trouble is dumpbin and objdump might both be in the PATH on Windows. You don't really know which one to use. I wonder if you found both if you could call something on each of them with one of the binaries, if you could figure out what tool would work better with it. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation
Hi Clint Am 29.07.2015 um 16:47 schrieb Clinton Stimpson: > On Wednesday, July 29, 2015 04:05:41 PM Pascal Bach wrote: >> Hi Clint >> >> Am 29.07.2015 um 15:45 schrieb Clinton Stimpson: >>> Hi Pascal, >>> >>> Thanks for the patches. >>> >>> Can you share with us why setting CMAKE_FIND_ROOT_PATH does not work, or >>> how this new method compares? >>> >>> For example, in the toolchain file: >>> SET(CMAKE_FIND_ROOT_PATH /path/to/Qt ...) >> The problem is how FindQt4 does find the locations using qmake. >> >> let's assume there are two sysroots one is /sysroots/x86_64 which contains >> binaries usable on the host machine, and there is /sysroots/arm which >> contains libraries for the target system. this are both set via: >> set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64) >> set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY ) >> set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY ) >> set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY ) >> set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY ) > Yes, this concern of 2 sysroots has been brought up before. Thanks for > addressing this. > >> Here is what happens when only setting CMAKE_FIND_ROOT_PATH: >> >> 1. FindQt4 is trying to find the qmake executable. As there is no qmake in >> /sysroots/arm (it would not be runnable on the host) it will find qmake >> from the /sysroots/x86_64 directory. 2. FindQt4 is asking qmake for the >> path to the Qt installation. As the qmake found is the one from >> /sysroots/x86_64 it will point to the libraries from /sysroots/x86_64 which >> will obviously not run on arm! >> >> Currently I didn't find a way to override this behaviour of FindQt4, except >> by setting all the variables usually set by FindQt4 manually. It is usually >> accepted to set some variables manually when doing cross compilation. With >> this patchset I tried to reduce this variable to a minumum and let FindQt4 >> figure out the rest. >> >> The minimum variables required with the patch are: >> >> QT_BINARY_DIR is necessary to find the correct qmake >> QT_LIBRARY_DIR is necessary to find the library directory >> QT_INCLUDE_DIR is necessary to find the include directory (might be possible >> to figure this out from QT_INCLUDE_DIR if some assumptions are made) >> QT_MKSPECS_DIR necessary to have the correct prefixes (E in the case of >> qt4-embedded). >> >> >> I hope my explanation is clear. If there is a better way to achive this I'm >> all ears. >> > I'm fine with this, and don't think it'll conflict with any other use cases. I don't see a conflict either. > > However, I do think we should first document setting CMAKE_FIND_ROOT_PATH, > then > afterwards document the other variables for those users which need more > control. Does that sound reasonable? I'm not sure I understand what you mean. I think how to set CMAKE_FIND_ROOT_PATH is already documented in cmake. Are you suggesting extending the docuemntation of FindQt4below with a paragraph documenting how to work with two sysroots? With an example like this? set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64) set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY ) set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY ) set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY ) set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY ) Pascal > > Clint > >> Pascal >> >>> Clint >>> >>> On Wednesday, July 29, 2015 02:32:48 PM Pascal Bach wrote: --- Modules/FindQt4.cmake | 20 1 file changed, 20 insertions(+) diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake index 9d03378..64c06e1 100644 --- a/Modules/FindQt4.cmake +++ b/Modules/FindQt4.cmake @@ -29,6 +29,26 @@ # for a particular executable, set the ``QT4_NO_LINK_QTMAIN`` target # property to ``TRUE`` on the executable. # +# Cross Compile +# ^ +# +# To find Qt in a cross compile environment set the following variables in your toolchain file: +# +# +# ``QT_BINARY_DIR`` => Path to native Qt binary directory +# ``QT_LIBRARY_DIR`` => Path to target Qt library directory +# ``QT_INCLUDE_DIR`` => Path to target Qt include directory +# ``QT_MKSPECS_DIR`` => Path to target Qt mkspecs directory + +# example +# +# :: +# set( QT_BINARY_DIR /sysroots/x86_64-linux/usr/bin ) +# set( QT_LIBRARY_DIR /sysroots/arm/usr/lib ) +# set( QT_INCLUDE_DIR /sysroots/arm/usr/include/qtopia ) +# set( QT_MKSPECS_DIR /sysroots/arm/usr/share/qtopia/mkspecs ) +# +# # Qt Build Tools # ^^ # -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training C
Re: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation
On Wednesday, July 29, 2015 04:05:41 PM Pascal Bach wrote: > Hi Clint > > Am 29.07.2015 um 15:45 schrieb Clinton Stimpson: > > Hi Pascal, > > > > Thanks for the patches. > > > > Can you share with us why setting CMAKE_FIND_ROOT_PATH does not work, or > > how this new method compares? > > > > For example, in the toolchain file: > > SET(CMAKE_FIND_ROOT_PATH /path/to/Qt ...) > > The problem is how FindQt4 does find the locations using qmake. > > let's assume there are two sysroots one is /sysroots/x86_64 which contains > binaries usable on the host machine, and there is /sysroots/arm which > contains libraries for the target system. this are both set via: > set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64) > set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY ) Yes, this concern of 2 sysroots has been brought up before. Thanks for addressing this. > > Here is what happens when only setting CMAKE_FIND_ROOT_PATH: > > 1. FindQt4 is trying to find the qmake executable. As there is no qmake in > /sysroots/arm (it would not be runnable on the host) it will find qmake > from the /sysroots/x86_64 directory. 2. FindQt4 is asking qmake for the > path to the Qt installation. As the qmake found is the one from > /sysroots/x86_64 it will point to the libraries from /sysroots/x86_64 which > will obviously not run on arm! > > Currently I didn't find a way to override this behaviour of FindQt4, except > by setting all the variables usually set by FindQt4 manually. It is usually > accepted to set some variables manually when doing cross compilation. With > this patchset I tried to reduce this variable to a minumum and let FindQt4 > figure out the rest. > > The minimum variables required with the patch are: > > QT_BINARY_DIR is necessary to find the correct qmake > QT_LIBRARY_DIR is necessary to find the library directory > QT_INCLUDE_DIR is necessary to find the include directory (might be possible > to figure this out from QT_INCLUDE_DIR if some assumptions are made) > QT_MKSPECS_DIR necessary to have the correct prefixes (E in the case of > qt4-embedded). > > > I hope my explanation is clear. If there is a better way to achive this I'm > all ears. > I'm fine with this, and don't think it'll conflict with any other use cases. However, I do think we should first document setting CMAKE_FIND_ROOT_PATH, then afterwards document the other variables for those users which need more control. Does that sound reasonable? Clint > Pascal > > > Clint > > > > On Wednesday, July 29, 2015 02:32:48 PM Pascal Bach wrote: > >> --- > >> > >> Modules/FindQt4.cmake | 20 > >> 1 file changed, 20 insertions(+) > >> > >> diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake > >> index 9d03378..64c06e1 100644 > >> --- a/Modules/FindQt4.cmake > >> +++ b/Modules/FindQt4.cmake > >> @@ -29,6 +29,26 @@ > >> > >> # for a particular executable, set the ``QT4_NO_LINK_QTMAIN`` target > >> # property to ``TRUE`` on the executable. > >> # > >> > >> +# Cross Compile > >> +# ^ > >> +# > >> +# To find Qt in a cross compile environment set the following variables > >> in > >> your toolchain file: +# > >> +# > >> +# ``QT_BINARY_DIR`` => Path to native Qt binary directory > >> +# ``QT_LIBRARY_DIR`` => Path to target Qt library directory > >> +# ``QT_INCLUDE_DIR`` => Path to target Qt include directory > >> +# ``QT_MKSPECS_DIR`` => Path to target Qt mkspecs directory > >> + > >> +# example > >> +# > >> +# :: > >> +# set( QT_BINARY_DIR /sysroots/x86_64-linux/usr/bin ) > >> +# set( QT_LIBRARY_DIR /sysroots/arm/usr/lib ) > >> +# set( QT_INCLUDE_DIR /sysroots/arm/usr/include/qtopia ) > >> +# set( QT_MKSPECS_DIR /sysroots/arm/usr/share/qtopia/mkspecs ) > >> +# > >> +# > >> > >> # Qt Build Tools > >> # ^^ > >> # -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modules/GetPrequisites.cmake issues
On 29/07/2015 14:37, Brad King wrote:
Hi Brad,
On 07/28/2015 06:02 PM, Bill Somerville wrote:
...
As there doesn't seem to be a reliable way of detecting MinGW callers
of fixup_bundle() may have to set the variable gp_tool to "objdump" if
dumpbin.exe is installed on the build machine to stop it using
dumpbin.exe for library dependency walking.
Is there a reason not to look for objdump before dumpbin?
I was under the impression that dumpbin was selected first for non-MinGW
Windows builds, I have no idea if objdump works with binaries produced
by compilers other than GNU/CLang. This is why I commented about
detecting MinGW, there are mentions of a MINGW CMake system variable but
it doesn't seem to exist.
This patch also adds command status checking to the various
execute_process() invocations in GetPrerequisites.cmake so that they
don't fail silently producing invalid install packages.
If you're comfortable enough with Git, please split this part out into
a preceding patch with its own explanation in its commit message. That
will clarify which hunks in the patch belong to which change.
No problem with that, I will do that shortly.
+ if(gp_cmd_filter) # filter is for performance
+execute_process(
+ COMMAND ${gp_cmd} ${gp_cmd_args} ${target}
+ COMMAND ${gp_grep_cmd} ${gp_cmd_filter}
+ RESULT_VARIABLE gp_rv
+ OUTPUT_VARIABLE gp_cmd_ov
+ ERROR_VARIABLE gp_ev
+ )
+ else()
+execute_process(
+ COMMAND ${gp_cmd} ${gp_cmd_args} ${target}
+ RESULT_VARIABLE gp_rv
+ OUTPUT_VARIABLE gp_cmd_ov
+ ERROR_VARIABLE gp_ev
+ )
+ endif()
This can be simplified as:
execute_process(
COMMAND ${gp_cmd} ${gp_cmd_args} ${target}
${gp_cmd_maybe_filter}
RESULT_VARIABLE gp_rv
OUTPUT_VARIABLE gp_cmd_ov
ERROR_VARIABLE gp_ev
)
where ``gp_cmd_maybe_filter`` is initialized to empty and later
possibly set as:
if(gp_grep_cmd)
set(gp_cmd_maybe_filter
COMMAND ${gp_grep_cmd} "^[[:blank:]]*DLL Name: "
)
endif()
I tried that first but couldn't get it to work, maybe because I didn't
initialize it to empty, I will try again.
Thanks,
-Brad
Thanks for the review,
regards
Bill Somerville.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation
Hi Pascal, Thanks for the patches. Can you share with us why setting CMAKE_FIND_ROOT_PATH does not work, or how this new method compares? For example, in the toolchain file: SET(CMAKE_FIND_ROOT_PATH /path/to/Qt ...) Clint On Wednesday, July 29, 2015 02:32:48 PM Pascal Bach wrote: > --- > Modules/FindQt4.cmake | 20 > 1 file changed, 20 insertions(+) > > diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake > index 9d03378..64c06e1 100644 > --- a/Modules/FindQt4.cmake > +++ b/Modules/FindQt4.cmake > @@ -29,6 +29,26 @@ > # for a particular executable, set the ``QT4_NO_LINK_QTMAIN`` target > # property to ``TRUE`` on the executable. > # > +# Cross Compile > +# ^ > +# > +# To find Qt in a cross compile environment set the following variables in > your toolchain file: +# > +# > +# ``QT_BINARY_DIR`` => Path to native Qt binary directory > +# ``QT_LIBRARY_DIR`` => Path to target Qt library directory > +# ``QT_INCLUDE_DIR`` => Path to target Qt include directory > +# ``QT_MKSPECS_DIR`` => Path to target Qt mkspecs directory > + > +# example > +# > +# :: > +# set( QT_BINARY_DIR /sysroots/x86_64-linux/usr/bin ) > +# set( QT_LIBRARY_DIR /sysroots/arm/usr/lib ) > +# set( QT_INCLUDE_DIR /sysroots/arm/usr/include/qtopia ) > +# set( QT_MKSPECS_DIR /sysroots/arm/usr/share/qtopia/mkspecs ) > +# > +# > # Qt Build Tools > # ^^ > # -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation
Hi Clint Am 29.07.2015 um 15:45 schrieb Clinton Stimpson: > Hi Pascal, > > Thanks for the patches. > > Can you share with us why setting CMAKE_FIND_ROOT_PATH does not work, or how > this new method compares? > > For example, in the toolchain file: > SET(CMAKE_FIND_ROOT_PATH /path/to/Qt ...) The problem is how FindQt4 does find the locations using qmake. let's assume there are two sysroots one is /sysroots/x86_64 which contains binaries usable on the host machine, and there is /sysroots/arm which contains libraries for the target system. this are both set via: set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64) set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY ) set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY ) set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY ) set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY ) Here is what happens when only setting CMAKE_FIND_ROOT_PATH: 1. FindQt4 is trying to find the qmake executable. As there is no qmake in /sysroots/arm (it would not be runnable on the host) it will find qmake from the /sysroots/x86_64 directory. 2. FindQt4 is asking qmake for the path to the Qt installation. As the qmake found is the one from /sysroots/x86_64 it will point to the libraries from /sysroots/x86_64 which will obviously not run on arm! Currently I didn't find a way to override this behaviour of FindQt4, except by setting all the variables usually set by FindQt4 manually. It is usually accepted to set some variables manually when doing cross compilation. With this patchset I tried to reduce this variable to a minumum and let FindQt4 figure out the rest. The minimum variables required with the patch are: QT_BINARY_DIR is necessary to find the correct qmake QT_LIBRARY_DIR is necessary to find the library directory QT_INCLUDE_DIR is necessary to find the include directory (might be possible to figure this out from QT_INCLUDE_DIR if some assumptions are made) QT_MKSPECS_DIR necessary to have the correct prefixes (E in the case of qt4-embedded). I hope my explanation is clear. If there is a better way to achive this I'm all ears. Pascal > > Clint > > On Wednesday, July 29, 2015 02:32:48 PM Pascal Bach wrote: >> --- >> Modules/FindQt4.cmake | 20 >> 1 file changed, 20 insertions(+) >> >> diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake >> index 9d03378..64c06e1 100644 >> --- a/Modules/FindQt4.cmake >> +++ b/Modules/FindQt4.cmake >> @@ -29,6 +29,26 @@ >> # for a particular executable, set the ``QT4_NO_LINK_QTMAIN`` target >> # property to ``TRUE`` on the executable. >> # >> +# Cross Compile >> +# ^ >> +# >> +# To find Qt in a cross compile environment set the following variables in >> your toolchain file: +# >> +# >> +# ``QT_BINARY_DIR`` => Path to native Qt binary directory >> +# ``QT_LIBRARY_DIR`` => Path to target Qt library directory >> +# ``QT_INCLUDE_DIR`` => Path to target Qt include directory >> +# ``QT_MKSPECS_DIR`` => Path to target Qt mkspecs directory >> + >> +# example >> +# >> +# :: >> +# set( QT_BINARY_DIR /sysroots/x86_64-linux/usr/bin ) >> +# set( QT_LIBRARY_DIR /sysroots/arm/usr/lib ) >> +# set( QT_INCLUDE_DIR /sysroots/arm/usr/include/qtopia ) >> +# set( QT_MKSPECS_DIR /sysroots/arm/usr/share/qtopia/mkspecs ) >> +# >> +# >> # Qt Build Tools >> # ^^ >> # -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Java support
Thanks for your comments. To address your first remark, I propose to introduce a new component (‘Extra', for example) to manage these new tools. For example: find_package (Java COMPONENTS Development Extra) I think it is better than removing new variables as required because this approach will require some explicit check to ensure these tools are found before usage. Regarding your second remark, I will update my patches. Marc On 29/07/15 15:47, "Brad King" wrote: >On 07/29/2015 04:01 AM, CHEVRIER, Marc wrote: >> here is an updated list of patches. > >Great. > >>find_package_handle_standard_args(Java >> REQUIRED_VARS Java_JAVA_EXECUTABLE Java_JAR_EXECUTABLE >> Java_JAVAC_EXECUTABLE >>Java_JAVAH_EXECUTABLE Java_JAVADOC_EXECUTABLE >> + Java_IDLJ_EXECUTABLE Java_JARSIGNER_EXECUTABLE >> VERSION_VAR Java_VERSION >> ) > >Are idlj and jarsigner reliably available whenever the other tools are? >Even for older versions? Do these need to be REQUIRED_VARS? I'm >concerned this could make a case that previously found java not report >it found anymore. > >> - --build-project hello >> + --build-target hello > >The tests should still have --build-project as this corresponds to >the .sln file name in Visual Studio builds. The --build-target >option can be added in addition to it. > >Thanks, >-Brad > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Java support
On 07/29/2015 04:01 AM, CHEVRIER, Marc wrote: > here is an updated list of patches. Great. >find_package_handle_standard_args(Java > REQUIRED_VARS Java_JAVA_EXECUTABLE Java_JAR_EXECUTABLE > Java_JAVAC_EXECUTABLE >Java_JAVAH_EXECUTABLE Java_JAVADOC_EXECUTABLE > + Java_IDLJ_EXECUTABLE Java_JARSIGNER_EXECUTABLE > VERSION_VAR Java_VERSION > ) Are idlj and jarsigner reliably available whenever the other tools are? Even for older versions? Do these need to be REQUIRED_VARS? I'm concerned this could make a case that previously found java not report it found anymore. > - --build-project hello > + --build-target hello The tests should still have --build-project as this corresponds to the .sln file name in Visual Studio builds. The --build-target option can be added in addition to it. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modules/GetPrequisites.cmake issues
On 07/28/2015 06:02 PM, Bill Somerville wrote:
> attached is a patch that addresses some issues recently discussed on the
> users list.
Thanks for working on this!
> As there doesn't seem to be a reliable way of detecting MinGW callers
> of fixup_bundle() may have to set the variable gp_tool to "objdump" if
> dumpbin.exe is installed on the build machine to stop it using
> dumpbin.exe for library dependency walking.
Is there a reason not to look for objdump before dumpbin?
> This patch also adds command status checking to the various
> execute_process() invocations in GetPrerequisites.cmake so that they
> don't fail silently producing invalid install packages.
If you're comfortable enough with Git, please split this part out into
a preceding patch with its own explanation in its commit message. That
will clarify which hunks in the patch belong to which change.
> + if(gp_cmd_filter) # filter is for performance
> +execute_process(
> + COMMAND ${gp_cmd} ${gp_cmd_args} ${target}
> + COMMAND ${gp_grep_cmd} ${gp_cmd_filter}
> + RESULT_VARIABLE gp_rv
> + OUTPUT_VARIABLE gp_cmd_ov
> + ERROR_VARIABLE gp_ev
> + )
> + else()
> +execute_process(
> + COMMAND ${gp_cmd} ${gp_cmd_args} ${target}
> + RESULT_VARIABLE gp_rv
> + OUTPUT_VARIABLE gp_cmd_ov
> + ERROR_VARIABLE gp_ev
> + )
> + endif()
This can be simplified as:
execute_process(
COMMAND ${gp_cmd} ${gp_cmd_args} ${target}
${gp_cmd_maybe_filter}
RESULT_VARIABLE gp_rv
OUTPUT_VARIABLE gp_cmd_ov
ERROR_VARIABLE gp_ev
)
where ``gp_cmd_maybe_filter`` is initialized to empty and later
possibly set as:
if(gp_grep_cmd)
set(gp_cmd_maybe_filter
COMMAND ${gp_grep_cmd} "^[[:blank:]]*DLL Name: "
)
endif()
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Add command line options for deprecation message control
On 07/27/2015 07:07 PM, Michael Scott wrote: > I've changed the -W dev options to affect the deprecated warnings/errors > as well, but only if the user hasn't used one of the options that > control deprecated warnings (-Wdeprecated, -Wno-deprecated, > -Werror=deprecated, -Wno-error=deprecated), if they have then the -W dev > options won't affect the CMAKE_WARN_DEPRECATED or CMAKE_ERROR_DEPRECATED > variables. > > I've also added the two -W dev options, "-Werror=dev" and > "-Wno-error=dev", to bring this set of options in line with the > deprecated set of options. Great! I've applied the patch with a few tweaks: cmake: Add -W options to control deprecation warnings and errors http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c96fe0b4 The largest change is that I hid CMAKE_SUPPRESS_DEVELOPER_ERRORS from public documentation since it is just an implementation detail to store the corresponding options persistently. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH 0/3] improve FindQt4 and crosscompilation
This patch set tries to improve how FindQt4 works in a cross compilation environment. In this case OpenEmbedded/Yoctor, but others should benefit from this too. Pascal Bach (3): FindQt4: support OpenEmbedded Qt4 tool binary names FindQt4: improve cross compile support FindQt4: document cross compilation Modules/FindQt4.cmake | 42 +++--- 1 file changed, 31 insertions(+), 11 deletions(-) -- 1.9.1 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH 3/3] FindQt4: document cross compilation
--- Modules/FindQt4.cmake | 20 1 file changed, 20 insertions(+) diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake index 9d03378..64c06e1 100644 --- a/Modules/FindQt4.cmake +++ b/Modules/FindQt4.cmake @@ -29,6 +29,26 @@ # for a particular executable, set the ``QT4_NO_LINK_QTMAIN`` target # property to ``TRUE`` on the executable. # +# Cross Compile +# ^ +# +# To find Qt in a cross compile environment set the following variables in your toolchain file: +# +# +# ``QT_BINARY_DIR`` => Path to native Qt binary directory +# ``QT_LIBRARY_DIR`` => Path to target Qt library directory +# ``QT_INCLUDE_DIR`` => Path to target Qt include directory +# ``QT_MKSPECS_DIR`` => Path to target Qt mkspecs directory + +# example +# +# :: +# set( QT_BINARY_DIR /sysroots/x86_64-linux/usr/bin ) +# set( QT_LIBRARY_DIR /sysroots/arm/usr/lib ) +# set( QT_INCLUDE_DIR /sysroots/arm/usr/include/qtopia ) +# set( QT_MKSPECS_DIR /sysroots/arm/usr/share/qtopia/mkspecs ) +# +# # Qt Build Tools # ^^ # -- 1.9.1 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH 2/3] FindQt4: improve cross compile support
FindQt4 depends a lot on QMake for finding the correct Qt path.
This doesn't work well in cross compile environments as qmake reports
the location of the native library.
This patch allows to do cross compilation by setting the following variables
for example in the toolchain file.
QT_BINARY_DIR => Path to native Qt binary directory
QT_LIBRARY_DIR => Path to target Qt library directory
QT_INCLUDE_DIR => Path to target Qt include directory
QT_MKSPECS_DIR => Path to target Qt mkspecs directory
Signed-off-by: Pascal Bach
---
Modules/FindQt4.cmake | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
index 14404fa..9d03378 100644
--- a/Modules/FindQt4.cmake
+++ b/Modules/FindQt4.cmake
@@ -583,23 +583,23 @@ if (QT_QMAKE_EXECUTABLE AND
set(QT_QTCORE_LIBRARY_DEBUG NOTFOUND)
find_library(QT_QTCORE_LIBRARY_RELEASE
NAMES QtCore${QT_LIBINFIX} QtCore${QT_LIBINFIX}4
- HINTS ${QT_LIBRARY_DIR_TMP}
+ HINTS ${QT_LIBRARY_DIR} ${QT_LIBRARY_DIR_TMP}
NO_DEFAULT_PATH
)
find_library(QT_QTCORE_LIBRARY_DEBUG
NAMES QtCore${QT_LIBINFIX}_debug QtCore${QT_LIBINFIX}d
QtCore${QT_LIBINFIX}d4
- HINTS ${QT_LIBRARY_DIR_TMP}
+ HINTS ${QT_LIBRARY_DIR} ${QT_LIBRARY_DIR_TMP}
NO_DEFAULT_PATH
)
if(NOT QT_QTCORE_LIBRARY_RELEASE AND NOT QT_QTCORE_LIBRARY_DEBUG)
find_library(QT_QTCORE_LIBRARY_RELEASE
NAMES QtCore${QT_LIBINFIX} QtCore${QT_LIBINFIX}4
- HINTS ${QT_LIBRARY_DIR_TMP}
+ HINTS ${QT_LIBRARY_DIR} ${QT_LIBRARY_DIR_TMP}
)
find_library(QT_QTCORE_LIBRARY_DEBUG
NAMES QtCore${QT_LIBINFIX}_debug QtCore${QT_LIBINFIX}d
QtCore${QT_LIBINFIX}d4
- HINTS ${QT_LIBRARY_DIR_TMP}
+ HINTS ${QT_LIBRARY_DIR} ${QT_LIBRARY_DIR_TMP}
)
endif()
@@ -659,13 +659,13 @@ if (QT_QMAKE_EXECUTABLE AND
_qt4_query_qmake(QT_INSTALL_HEADERS qt_headers)
set(QT_QTCORE_INCLUDE_DIR NOTFOUND)
find_path(QT_QTCORE_INCLUDE_DIR QtCore
-HINTS ${qt_headers} ${QT_LIBRARY_DIR}
+HINTS ${QT_INCLUDE_DIR} ${qt_headers} ${QT_LIBRARY_DIR}
PATH_SUFFIXES QtCore qt4/QtCore
NO_DEFAULT_PATH
)
if(NOT QT_QTCORE_INCLUDE_DIR)
find_path(QT_QTCORE_INCLUDE_DIR QtCore
- HINTS ${qt_headers} ${QT_LIBRARY_DIR}
+ HINTS ${QT_INCLUDE_DIR} ${qt_headers} ${QT_LIBRARY_DIR}
PATH_SUFFIXES QtCore qt4/QtCore
)
endif()
--
1.9.1
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH 1/3] FindQt4: support OpenEmbedded Qt4 tool binary names
The FindQt4 module looks for Qt4 binaries to be able to gather the
paths used for compilation and also to be using during other processes
(translation update, translation binary generating and like) however
OpenEmbedded has renamed those to allow old QMake to be used in
parallel with the current one. This patch adds support for the
OpenEmbedded specific binary names.
This patch was maintained as part of OpenEmbedded.
Signed-off-by: Otavio Salvador
Signed-off-by: Moritz Blume
Signed-off-by: Pascal Bach
---
Modules/FindQt4.cmake | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
index 11091b5..14404fa 100644
--- a/Modules/FindQt4.cmake
+++ b/Modules/FindQt4.cmake
@@ -522,7 +522,7 @@ endfunction()
set(QT4_INSTALLED_VERSION_TOO_OLD FALSE)
-set(_QT4_QMAKE_NAMES qmake qmake4 qmake-qt4 qmake-mac)
+set(_QT4_QMAKE_NAMES qmake qmake2 qmake4 qmake-qt4 qmake-mac)
_qt4_find_qmake("${_QT4_QMAKE_NAMES}" QT_QMAKE_EXECUTABLE QTVERSION)
if (QT_QMAKE_EXECUTABLE AND
@@ -1148,12 +1148,12 @@ if (QT_QMAKE_EXECUTABLE AND
_find_qt4_program(QT_MOC_EXECUTABLE Qt4::moc moc-qt4 moc4 moc)
_find_qt4_program(QT_UIC_EXECUTABLE Qt4::uic uic-qt4 uic4 uic)
_find_qt4_program(QT_UIC3_EXECUTABLE Qt4::uic3 uic3)
- _find_qt4_program(QT_RCC_EXECUTABLE Qt4::rcc rcc)
- _find_qt4_program(QT_DBUSCPP2XML_EXECUTABLE Qt4::qdbuscpp2xml qdbuscpp2xml)
- _find_qt4_program(QT_DBUSXML2CPP_EXECUTABLE Qt4::qdbusxml2cpp qdbusxml2cpp)
+ _find_qt4_program(QT_RCC_EXECUTABLE Qt4::rcc rcc4 rcc)
+ _find_qt4_program(QT_DBUSCPP2XML_EXECUTABLE Qt4::qdbuscpp2xml qdbuscpp2xml4
qdbuscpp2xml)
+ _find_qt4_program(QT_DBUSXML2CPP_EXECUTABLE Qt4::qdbusxml2cpp qdbusxml2cpp4
qdbusxml2cpp)
_find_qt4_program(QT_LUPDATE_EXECUTABLE Qt4::lupdate lupdate-qt4 lupdate4
lupdate)
_find_qt4_program(QT_LRELEASE_EXECUTABLE Qt4::lrelease lrelease-qt4
lrelease4 lrelease)
- _find_qt4_program(QT_QCOLLECTIONGENERATOR_EXECUTABLE
Qt4::qcollectiongenerator qcollectiongenerator-qt4 qcollectiongenerator)
+ _find_qt4_program(QT_QCOLLECTIONGENERATOR_EXECUTABLE
Qt4::qcollectiongenerator qcollectiongenerator-qt4 qcollectiongenerator4
qcollectiongenerator)
_find_qt4_program(QT_DESIGNER_EXECUTABLE Qt4::designer designer-qt4
designer4 designer)
_find_qt4_program(QT_LINGUIST_EXECUTABLE Qt4::linguist linguist-qt4
linguist4 linguist)
--
1.9.1
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015669]: XCTest for iOS target has incorrect TEST_HOST
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15669 == Reported By:Seppo Tomperi Assigned To: == Project:CMake Issue ID: 15669 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-29 08:07 EDT Last Modified: 2015-07-29 08:07 EDT == Summary:XCTest for iOS target has incorrect TEST_HOST Description: Path to executable in TEST_HOST is not correct when targeting iOS device. Steps to Reproduce: unzip iOSNavAppXCTest.zip cd iOSNavAppXCTest mkdir build cd build cmake -G Xcode .. grep TEST_HOST NavApp3.xcodeproj/project.pbxproj TEST_HOST variable has extra directory: "Contents/MacOS", which is not there. Executable is in NavApp3.app-directory. If "Contents/MacOS" is edited away from project file then project works and XCTests can be run in simulator and on iPhone. == Issue History Date ModifiedUsername FieldChange == 2015-07-29 08:07 Seppo Tomperi New Issue 2015-07-29 08:07 Seppo Tomperi File Added: iOSNavAppXCTest.zip == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015668]: Create debuginfo package
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15668 == Reported By:Egor Assigned To: == Project:CMake Issue ID: 15668 Category: CPack Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2015-07-29 04:26 EDT Last Modified: 2015-07-29 04:26 EDT == Summary:Create debuginfo package Description: CPack allows us to create rpm-packages through CPackRPM module, but there is no chance to ask him for building correspondent debuginfo rpm package. == Issue History Date ModifiedUsername FieldChange == 2015-07-29 04:26 Egor New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Java support
Hi, You are right. @ must be matching at the beginning of the item. But I need .* in the expression because I use regex matching group to retrieve filename. Anyway, here is an updated list of patches. Marc On 29/07/15 09:25, "cmake-developers on behalf of Rolf Eike Beer" wrote: >Am Dienstag, 28. Juli 2015, 08:15:01 schrieb CHEVRIER, Marc: >> Hi, >> >> 0002 (UseJava.cmake): Extends add_jar command to support @file syntax for >> java sources specification. > >You do not need leading or trailing .* in regular expressions. In fact I think >your expression should simply be "^@", otherwise you would match an @ at any >position in the argument name, which does not look intended. > >Greetings, > >Eike 0001-Add-support-for-idlj-and-jarsigner-tools.patch Description: 0001-Add-support-for-idlj-and-jarsigner-tools.patch 0002-add_jar-now-supports-file-syntax-for-sources.patch Description: 0002-add_jar-now-supports-file-syntax-for-sources.patch 0003-install_jar-Add-options-DESTINATION-and-COMPONENT.patch Description: 0003-install_jar-Add-options-DESTINATION-and-COMPONENT.patch 0004-Add-support-for-javah-tool.patch Description: 0004-Add-support-for-javah-tool.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Java support
Am Dienstag, 28. Juli 2015, 08:15:01 schrieb CHEVRIER, Marc: > Hi, > > 0002 (UseJava.cmake): Extends add_jar command to support @file syntax for > java sources specification. You do not need leading or trailing .* in regular expressions. In fact I think your expression should simply be "^@", otherwise you would match an @ at any position in the argument name, which does not look intended. Greetings, Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
