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
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
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
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
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
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 ^@,
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15668
==
Reported By:Egor
Assigned To:
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15667
==
Reported By:Seppo Tomperi
Assigned To:
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15669
==
Reported By:Seppo Tomperi
Assigned To:
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
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
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
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
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
---
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
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
+
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
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
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
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:
---
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
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
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
23 matches
Mail list logo
