I use a different directory to build release and debug versions
if you didn't delete, then when it goes to build partial things, the .obj
files will still be newer than the .c files and will cause mixed
release-debug builds which generally results in bizarre crashes.
Once chosen, can't change
On Tuesday, February 24, 2015 20:14:23 Stephen Kelly wrote:
Jifeng ZHANG wrote:
Any idea when CMake 4.0 is planned to release? So we can get a general
idea when the old behavior will stop working.
What will you do when it is released and the LOCATION property does stop
working for build
Hello all,
I've browsed this thread:
http://www.cmake.org/pipermail/cmake/2008-September/023808.html
But it doesn't work. My project is set to Release regardless, whether I do:
project( CDT-plusplus_ )
set(CMAKE_BUILD_TYPE RelWithDebInfo)
Or:
#
# If the user specifies -DCMAKE_BUILD_TYPE 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 1f09ba7030818eb51d5abd9f32e0ae3c873c43e2 (commit)
via
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 d81a19c7edb2dffa9f4bdbdeadacc8cce16522b2 (commit)
via
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 0d9f208ce393702510ba29b3193f760a5cf71b63 (commit)
via
Thank you Steve and NoRulez.
We actually make some manipulations on the string (TEST_PATH) that
returned from get_target_property, before we pass it to add_test.
So if we directly pass the generator expression, it won't work. We
need to change this part obviously.
Any idea when CMake 4.0 is
Hi Roman,
you approach (CMAKE_XL_CreateExportList_FLAGS right after
${CMAKE_XL_CreateExportList} in XL.cmake and then add -X32/-X64 into
CMAKE_XL_CreateExportList_FLAGS in your CMakeLists.txt) did not work.
It generated the attached link.txt, where it did not replace
Hi all,
Several times I've read the last paragraph of the documentation of
module CMakeParseArguments, but I can't get my head around it.
Keywords terminate lists of values, e.g. if directly after a
one_value_keyword another recognized keyword follows, this is
interpreted as the
My guess is there's a not missing between would and result in
MY_INSTALL_DESTINATION set to
Petr
On Tue, Feb 24, 2015 at 12:05 PM, Marcel Loose lo...@astron.nl wrote:
Hi all,
Several times I've read the last paragraph of the documentation of module
CMakeParseArguments, but I can't get my
Thanks everyone for all the hints! After a closer look, cmake actual copying of
files is indeed just as fast as normal OS copy, tested after reboots everytime.
However, when the files are already present (all target up-to-date), it still
takes 50+ seconds for cmake to realize that all files
On 02/24/2015 09:51 AM, Robert Goulet wrote:
takes 50+ seconds for cmake to realize that all files don't need
to be copied
It's comparing the time stamps of every corresponding file.
On many filesystems that is faster than the actual copy.
Perhaps the log spam for every file in the console is
On 02/24/2015 10:03 AM, Robert Goulet wrote:
Yes comparing timestamp is the way to go, but why is it so slow in cmake?
I've never observed that being slow in practice.
You'll have to profile CMake while running in this case, or add
some print statements with high-precision timestamps to see
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 d608b74b92d989fb8ece93d7fdd729fe7ebc9cbe (commit)
via
I am proud to announce the CMake 3.2 second release candidate.
Sources and binaries are available at:
http://www.cmake.org/download/
http://www.cmake.org/files/v3.2/?C=M;O=D
Documentation is available at:
http://www.cmake.org/cmake/help/v3.2
Release notes appear below and are also
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 1c381be5e1c8d01288ab198520141da5f7d74a8f (commit)
via
Yes comparing timestamp is the way to go, but why is it so slow in cmake? I
added command to set it to lazy report and it saved 1 second. So it's something
else... I forgot to mention that there's a weird pause at the end after
installing all files... not sure what it's doing. It looks like
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15417
==
Reported By:Christophe Dumeunier
Assigned To:
I am proud to announce the CMake 3.2 second release candidate.
Sources and binaries are available at:
http://www.cmake.org/download/
http://www.cmake.org/files/v3.2/?C=M;O=D
Documentation is available at:
http://www.cmake.org/cmake/help/v3.2
Release notes appear below and are also
Ok I guess we have no other choice than go in and profile it then. Thanks for
the input.
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Tuesday, February 24, 2015 10:07 AM
To: Robert Goulet; Joshua Clayton
Cc: cmake-developers@cmake.org
Subject: Re:
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, master has been updated
via ac80f0f95fc7cfbad17c2a5656a87e346b9f298a (commit)
via
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 8c9e5f5e73a474ab208694007e0bee63cb801304 (commit)
via
On 02/24/2015 08:25 AM, Mark Abraham wrote:
Some modules shoud use CMAKE_REQUIRED_FLAGS, not CMAKE_REQUIRED_DEFINITIONS,
I think.
Actually both technically support any flags, but the latter
only for legacy reasons. I agree CMAKE_REQUIRED_FLAGS is
clearer for this purpose. I've applied the
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 99e58d5e35fef0bd797e0674e3be7ef26eb6da6b (commit)
via
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 62e71cadfed6f49104496c1dff176935f7fad6bd (commit)
via
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 78ac31774a09ecc1b257694896fc0e37105d3772 (commit)
via
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, master has been updated
via 133ab7a4476f97c5c524bd1e7dcb65efe7d6f810 (commit)
via
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, master has been updated
via 206ce77781d7f19a9877caab137d69cc5ce4bb05 (commit)
via
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, master has been updated
via d518aa79a4a7ab5659a7cd67ee9c9ba374b26001 (commit)
via
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 0e0a995d4909910e08d2c95dfd95c336b81ab89c (commit)
via
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, master has been updated
via 91234717f710c3922a03e8449bf12475b7d6f26b (commit)
via
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, master has been updated
via f67b8065f603392ca794cc6f5c07bbbe6b077526 (commit)
via
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, master has been updated
via 8366b1bd4fff38d2e928edee1f93acdee12365d4 (commit)
via
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, master has been updated
via 3bda0717b31aa63e906cbc6129674a9e046f1066 (commit)
via
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, master has been updated
via 41a16f07c3b57e05927ba7706a4e3cebd7768ddf (commit)
via
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, master has been updated
via 13f9f848defa75f7d728050b4d99d44b194642b2 (commit)
via
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 d170c90d0ad3b749355f15ad7f91f290d7329156 (commit)
via
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 7fd618ba818b0f9c30777971852482c4c8d8ee8a (commit)
via
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 c8dce2768943c1fa193e758936a251c9490b5fc7 (commit)
via
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 2a558989f553964140f612fc6d7d0cc3dcae1a19 (commit)
via
On 02/23/2015 11:33 PM, 刘铁刚 wrote:
Here is that cmake says when cmake nanamsg on Windows 8.1 and VS2013:
This is a well-tested platform combination.
Have you used CMake before on this machine?
System is unknown to cmake, create:
Platform/Windows to use this system, please send your config
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 1a0b06dd6dc08b5253ea12e9f1b55dee1ac803be (commit)
via
Hi Brad,
You are right! Thank you!
In fact, I did not make a whole installation.
what i did is only download and unzip the cmake-3.2.0-rc1-win32-x86.zip.
Now it works well on this machine after I installed it again with the
cmake-3.2.0-rc1-win32-x86.exe.
Thanks again!
2015-02-24 22:39
Dear users,
It has been a while since I used CMake and it's the first time I'm using it
on Windows/MSVC2013, so hopefully I'm not missing something obvious. I
tried to create the most basic example that shows the problem.
I'm trying to compile a subfolder of my Qt5 project into a shared library.
Jakob van Bethlehem wrote:
Dear users,
set(CMAKE_PREFIX_PATH C:/Qt/Qt5.4.0/5.4/msvc2013_64_opengl/lib/cmake)
Don't do this. Pass CMAKE_PREFIX_PATH as an argument to cmake.
The CMakeLists.txt file in the subfolder looks like this:
CMAKE_MINIMUM_REQUIRED(VERSION 3.0.0)
This has
I guess that would imply that not is missing twice,
[...] would not be empty [...]
and
[...] would not be set to TRUE [...].
Marcel.
On 24/02/15 12:31, Petr Kmoch wrote:
My guess is there's a not missing between would and result in
MY_INSTALL_DESTINATION set to
Petr
On Tue, Feb
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 172ea187ef9486df4e1fe41cb6c6774e86a8bd46 (commit)
via
Jifeng ZHANG wrote:
Any idea when CMake 4.0 is planned to release? So we can get a general
idea when the old behavior will stop working.
What will you do when it is released and the LOCATION property does stop
working for build targets? Whatever it is, any reason not to do it now?
Thanks,
On Tue, Feb 24, 2015 at 23:25:20 +0100, Stephen Kelly wrote:
Brad King wrote:
Some restrictions are there because we cannot safely evaluate the
$TARGET_OBJECTS in general for all generators. See the code
using EvaluateForBuildsystem.
TARGET_OBJECTS already may not be used by
Hello,
I have some source files generated as a part of build process, generated
using add_custom_command().
Building works fine, but would be nice to have generated source files to
be displayed in IDE project (QtCreator using CodeBlocks generator).
I tried to use add_custom_target(...
Stephen Kelly wrote:
For the diamond-usage problem, is there some way of utilizing the
COMPATIBLE_INTERFACES to deny the mixing of two libraries where each
built with an object libraries' objects? Having a property to trigger
that would be nice...
Yes, that's possible by adding an
Brad King wrote:
On 02/23/2015 07:50 PM, Ben Boeckel wrote:
We could also lift the restriction then. I'm fine with just dropping the
patch. Basically without it, all it blocks is
add_custom_{command,target} from using $TARGET_OBJECTS…which could be
useful for some obscure linker target CMake
20150224)
+set(CMake_VERSION_PATCH 20150225)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
53 matches
Mail list logo
