Hi,
A new Qt CI machine machine is hitting problems with the CMake unit tests:
http://thread.gmane.org/gmane.comp.lib.qt.devel/10746
Any idea what the problem could be there?
Thanks,
Steve
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Laszlo Papp wrote:
Hi,
Just found this post from Brad:
http://www.cmake.org/pipermail/cmake/2011-February/042556.html
I would suggest to improve the warning message. It is not exactly clear
why that happens to a user like me.
My colleague saw this warning in his cmake output when he was
You’re building a 32-bit CMake and trying to link it to a 64-bit Qt.
Why do you expect that should work?
From: Stephen Kelly
Sent: Wednesday, April 10, 2013 4:03 AM
To: cmake-developers@cmake.org
Hi,
A new Qt CI machine machine is hitting problems with the CMake unit tests:
On 04/10/2013 01:29 PM, David Cole wrote:
You’re building a 32-bit CMake and trying to link it to a 64-bit Qt.
Why do you expect that should work?
I'm not trying build CMake and I'm not trying to link CMake to Qt.
The Qt CI machines download CMake from
Eric Noulard wrote:
I don't know anything about building on Windows, so that might indeed be
the problem. Can you confirm that it's not a misunderstanding?
In http://thread.gmane.org/gmane.comp.lib.qt.devel/10746 we can read:
3-- Build started: Project: axserverapp, Configuration:
Stephen Kelly wrote:
So, how is the target 32bit/64bit determined? An option to cmake at cmake
time?
It seems to be determined by the generator:
http://stackoverflow.com/questions/3785976/cmake-generate-visual-studio-2008-solution-for-win32-and-x64
I'll figure out a way to determine that
2013/4/10 Stephen Kelly steve...@gmail.com
Stephen Kelly wrote:
So, how is the target 32bit/64bit determined? An option to cmake at cmake
time?
It seems to be determined by the generator:
- Original Message -
Eric Noulard wrote:
I don't know anything about building on Windows, so that might indeed be
the problem. Can you confirm that it's not a misunderstanding?
In http://thread.gmane.org/gmane.comp.lib.qt.devel/10746 we can read:
3-- Build started:
clin...@elemtech.com wrote:
It appears it needs more logic to handle the CMAKE_GENERATOR variable.
If a visual studio generator is going to be used, then it'll probably need
logic to determine which version of visual studio it is to choose the
correct visual studio generator (because of
On 04/10/2013 07:20 AM, Stephen Kelly wrote:
Is there any reason this variable shouldn't be special-cased in the unused
variable handling? If the special case is spelled correctly, it should be
fine.
If you want to add a whitelist to suppress the warning that's fine with me.
-Brad
--
Am 10.04.2013 16:17, schrieb Brad King:
On 04/10/2013 07:20 AM, Stephen Kelly wrote:
Is there any reason this variable shouldn't be special-cased in the
unused
variable handling? If the special case is spelled correctly, it
should be
fine.
If you want to add a whitelist to suppress the
On 04/10/2013 10:30 AM, Rolf Eike Beer wrote:
I think what Stephen had in mind (I really hope he had *g*) is to show
a different warning in that case, telling the user that the toolchain
file is ignored on any subsequent run.
Another approach is to not warn when the -DFOO=bar option just
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14070
==
Reported By:Jarle Aase
Assigned To:
Steve,
Since this commit:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=18a3195a
CMake crashes on the code
set_property(DIRECTORY PROPERTY INCLUDE_DIRECTORIES)
because code like
this-IncludeDirectoriesEntries.push_back(
cmValueWithOrigin(value, lfbt));
On 4/10/2013 11:54 AM, Stephen Kelly wrote:
(at the very bottom)
http://testresults.qt-project.org/ci/QtBase_stable_Integration/build_00894/win64-msvc2012_developer-build_qtnamespace_Windows_8/log.txt.gz
Any ideas?
I think you want this generator:
Visual Studio 11 Win64
-- Check for working C
Bill Hoffman wrote:
On 4/10/2013 11:54 AM, Stephen Kelly wrote:
(at the very bottom)
http://testresults.qt-project.org/ci/QtBase_stable_Integration/build_00894/win64-msvc2012_developer-build_qtnamespace_Windows_8/log.txt.gz
Any ideas?
I think you want this generator:
Visual Studio 11
On 4/10/2013 12:22 PM, Stephen Kelly wrote:
Yes, I think you're right. I've updated the patch with that information now.
Seems a bit unstable to hard code the version. I wonder if you can
detect the one that is being used somehow?
-Bill
--
Powered by www.kitware.com
Visit other Kitware
Brad King wrote:
On 04/10/2013 10:30 AM, Rolf Eike Beer wrote:
I think what Stephen had in mind (I really hope he had *g*) is to show
a different warning in that case, telling the user that the toolchain
file is ignored on any subsequent run.
Another approach is to not warn when the
Bill Hoffman wrote:
Seems a bit unstable to hard code the version. I wonder if you can
detect the one that is being used somehow?
I don't think it's unstable, but I do think the version and arch should be
detected somehow.
Would it be possible for cmake to run devenv to check the version
Stephen Kelly wrote:
Bill Hoffman wrote:
Seems a bit unstable to hard code the version. I wonder if you can
detect the one that is being used somehow?
I don't think it's unstable, but I do think the version and arch should be
detected somehow.
Would it be possible for cmake to run
On 4/10/2013 4:45 PM, Stephen Kelly wrote:
I don't think it's unstable, but I do think the version and arch should be
detected somehow.
I take it back.
It is not hard coded. It is just matching qt win32-msvc2010,
win32-msvc2012 with the correct CMake generator:
Bill Hoffman wrote:
What about VS 9, seems to be missing?
The Qt CI system only tests 2010 and 2012:
http://testresults.qt-project.org/ci/QtBase_dev_Integration/latest-success/
The wince70embedded-armv4i-msvc2008_Windows_7 build is currently failing for
other reasons, but it's a
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=14073
==
Reported By:Jean-Christophe Fillion-Robin
Assigned To:
Hi,
This is mostly just feedback on some experience with cross-compiling.
As part of trying to figure out to what extent Qt 5 needs to be patched to
solve the kind of issue raised in
http://public.kitware.com/Bug/view.php?id=14041
and fixed in 6c613b433c45efb0bb013a6bd668cbb8ac740259, I've
clin...@elemtech.com wrote:
I'm playing with some of the new cmake 2.8.11 features and an example I
saw had this:
set_property(TARGET foo PROPERTY
INTERFACE_INCLUDE_DIRECTORIES
$BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR};
${CMAKE_CURRENT_SOURCE_DIR}
Stephen Kelly wrote:
Where did you see the
example above? In an old commit message? It doesn't seem to be in the
code:
Ah, I found and fixed it on the wiki page:
http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements
Thanks,
Steve.
--
Powered by www.kitware.com
Yeah, that's it. Thanks. That page was referenced by a recent kitware blog.
http://www.kitware.com/blog/home/post/462
Clint
- Reply message -
From: Stephen Kelly steve...@gmail.com
Date: Wed, Apr 10, 2013 1:08 am
Subject: [CMake] INSTALL_INTERFACE question
To: cmake@cmake.org
Hi,
I like to disable the creation of the uninstall link in the windows
start menu when using the NSIS generator in combination with CMAKE and
CPACK.
When executing the generated NSIS installer using the standard
configuration of CPACK the uninstall link is automatically added to the
Sorry, but I have to keep complaining about the documentation. Please
excuse the ranting.
Just one example from the manual:
ctest --build-options: Add extra options to the build step.
This option must be the last option with the exception of
--test-command
End of available information.
Ralph Barth will be out of the office starting 10.04.2013 and will be
returning on 11.04.2013.
Ich werde Ihre Nachrichten nach meiner Rückkehr beantworten.
WLLM related questions pls. contact Sebastian Neusüß and Jens Keil.
Theo Price Feed from EDRE pls contact Jens Keil
Probably someone else can give you a better answer, but I ended up doing the
following:
ctest \
--build-and-test $SOURCE_DIR $BUILD_DIR \
--build-generator Unix Makefiles --build-makeprogram make \
-j $PARALLEL_JOBS \
--build-options -DCMAKE_CXX_COMPILER=$CXX -DCMAKE_C_COMPILER=$CC \
ctest has long been quite under-documented
There are some open issues in the bug tracker:
http://public.kitware.com/Bug/view.php?id=10392
http://public.kitware.com/Bug/view.php?id=13836
What's needed is someone to go in and do the work to document it well.
Until that happens, your best
On Wednesday 10 April 2013, Nico Schlömer wrote:
Sounds pretty good!
One question remains:
Suppose I have components A, B, C, where both A and B depend on C.
The link line that I'd pull in with
FIND_PACKAGE(Mypackage COMPONENTS A B)
Would be
A libs, C libs, B libs, C libs
where all
Hi all,
in a ProjectContfigTemplate.cmake.in file, I'd like to have variables
such as ${${PROJECT_NAME}_VERSION}. In ${}-syntax, the nesting is
recognized properly, and this string would be replaced by, e.g.,
2.1.
I know need to have ${}-variables in the output file, so I tried to
switch to the
2013/4/10 Nico Schlömer nico.schloe...@gmail.com
Hi all,
in a ProjectContfigTemplate.cmake.in file, I'd like to have variables
such as ${${PROJECT_NAME}_VERSION}. In ${}-syntax, the nesting is
recognized properly, and this string would be replaced by, e.g.,
2.1.
I know need to have
2013/4/10 Eric Noulard eric.noul...@gmail.com
2013/4/10 Nico Schlömer nico.schloe...@gmail.com
Replacing the above line by
@@PROJECT_NAME@_VERSION@
doesn't work however: The output file contains
@Myproject_VERSION@
i.e., only the inner variable was replaced.
How to fix this?
May
Nico,
I had this same problem at one point in time, but was able to change it to the
${...} syntax which works beautifully. I know that you cannot use this syntax,
but I will tell you that I did find a work-around for the nested @...@ syntax.
The workaround is to run configure_file on the file
Another workaround is to make an intermediate variable in the CMakeLists.txt
file and use this intermediate variable from the .in file. That elminates the
nested @@'s.
Clint
On Wednesday, April 10, 2013 07:51:03 PM Eric Clark wrote:
Nico,
I had this same problem at one point in time, but
So I have the same problem as the person in this old thread:
http://www.cmake.org/pipermail/cmake/2009-August/031671.html
I want to add some compile flags (currently using add_definitions) but they
mess up the rc.exe resource compiler.
Doing something like:
set_source_files_properties(hipchat.rc
On Wed, Apr 10, 2013 at 1:37 PM, Ian Monroe i...@monroe.nu wrote:
So I have the same problem as the person in this old thread:
http://www.cmake.org/pipermail/cmake/2009-August/031671.html
I want to add some compile flags (currently using add_definitions) but
they mess up the rc.exe resource
Hello,
Is there a convenient way to have CMake detect at build time additional
libraries that need to be linked for an external project to work? For
example, suppose I have
ExternalProject_Add(Foo ...args...)
which builds libfoo.a (which is an autotools package). Depending on the
system on
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 98f389eb19d3f56de0c8d68d50be7a3be6a3577a (commit)
via
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 7b07228..c4c987d 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -2,5 +2,5 @@
set(CMake_VERSION_MAJOR 2)
set(CMake_VERSION_MINOR 8)
set(CMake_VERSION_PATCH 10)
-set(CMake_VERSION_TWEAK 20130410
43 matches
Mail list logo
