On Tue, May 28, 2013 at 8:22 AM, Brad King brad.k...@kitware.com wrote:
On 05/26/2013 12:04 PM, Robert Dailey wrote:
I haven't gotten a response yet, I guess you guys stay pretty busy :)
Huh? I responded here:
On 05/29/2013 12:42 PM, Robert Dailey wrote:
I like your idea of using an external script to handle this, however,
there is certain state I need access to from the last CMake run.
Specifically, I have a variable with all of the 'bin' directories
where DLLs can be found. To avoid recursive
On Wed, May 29, 2013 at 1:22 PM, Brad King brad.k...@kitware.com wrote:
Configure the script with the list as part of its source using
configure_file.
Simply brilliant. I love the ideas you're giving me here. I've been
using CMake for years but I still miss out on coming up with good
ideas like
On 05/10/2013 06:41 AM, Stephen Kelly wrote:
* http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5680
(New INTERFACE_LINK_LIBRARIES policy approach)
I remember being quite happy with the proposal I made at the start of
that thread. Let's see if we can come up with something
On 2013-05-28 19:50, Wojciech Knapik wrote:
Files don't just happen to be lying around in directories. You have to
create them in a specific path, with a specific name. Even if the act of
creation was performed by another developer, on another machine, that
information is written to disk in the
On 2013-05-28 21:23, Wojciech Knapik wrote:
On Fri, May 24, 2013 at 11:21:57AM -0400, Matthew Woehlke wrote:
GLOB is just one of many things that will surprise you when working with
CMake if you don't understand the difference between the configure and
build passes.
I've written quite a bit
Hi Dan.
Note that the docs don't say that a custom target will always be built,
but that it's always considered out of date. That's something else. It
means that it will always be built *if building it is considered*. So
'make' will never skip it as up to date, but will not build it unless
told
Hello Eric,
thanks for your reply, i tried this, but in my case it doesn't work. I made
a function that first sets the configuration types (using your line of
code) and then calls the project function. Using this function instead of
the project function itself, still all configurations are beeing
Hi Janosch.
A solution to this problem which works for me is: if the configurations are
not those I want, set them correctly and abort the generation (with a help
message).
I put the following code into the CMakeList after the call to project():
if(CMAKE_CONFIGURATION_TYPES AND NOT
Hello, I'm trying to generate a Visual Studio 11 solution using v100
toolset and it is failing to compile a test program:
I run cmake -G Visual Studio 11 Win64 -T v100 path to source
-- The C compiler identification is MSVC 16.0.40219.1
-- The CXX compiler identification is MSVC 16.0.40219.1
--
Hello Petr,
i don't understand how this solves the problem, but indeed it does!
Still i have one small problem. To make regeneration of a clean project as
easy as possible, i have a batch file, which first clears all generated
data (including cmake cache), an then runs cmake. Since this fails now
I haven't looked into CMake code deep enough, so I don't really know how it
works either. Maybe project() stores something into the cache which causes
it to not trample over the configuration list in the next run. Just
guessing.
Petr
On Wed, May 29, 2013 at 4:40 PM, gaga bla gagab...@gmail.com
This is probably not related, but your comment about deleting the cmake
cache made me think of it: one thing to be sure of is that if you delete
CMakeCache.txt you ALSO delete the CMakeFiles/ directory.
Deleting CMakeCache.txt but not CMakeFiles yields corrupted results
after you run cmake the
On Wed, May 29, 2013 at 2:32 AM, Michael Wild them...@gmail.com wrote:
On 28.05.2013 22:07, Matthew Woehlke wrote:
Is there a built-in way to write a string to a file (a la FILE(WRITE))
that will only write the file if the content would be different? (Or
does FILE(WRITE) already work this
No love for this question apparently :-/
I tried to implement the suggestion in the mailing list post below, and
it works fine with UNIX makefiles.
But, on other generators such as Xcode and MSVC there's a major problem
that I don't know how to solve. The post suggests forcing a new target
like
Hello,
I'm using cmake to generate an Xcode project which is supposed to build a
bundle. Thus, I use the source file property MACOSX_PACKAGE_LOCATION to place
my data (database, GUI, localization files, …) in the correct directory in my
bundle.
I used to have a general CMakeLists.txt with
- Original Message -
Hello,
I'm using cmake to generate an Xcode project which is supposed to build a
bundle. Thus, I use the source file property MACOSX_PACKAGE_LOCATION to
place my data (database, GUI, localization files, …) in the correct
directory in my bundle.
I used to
- Reply message -
From: j s j.s4...@gmail.com
To: Michael Wild them...@gmail.com
Cc: CMake mailing list cmake@cmake.org
Subject: [CMake] write file if different?
Date: Wed, May 29, 2013 20:44
On Wed, May 29, 2013 at 2:32 AM, Michael Wild them...@gmail.com wrote:
On 28.05.2013 22:07,
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 450bb9d048d2101170a3ae29373d11fa7d90898a (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 40d4be09f4b86d6b022ed7e21acb07975e41b411 (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 f1977e36c024b42c8f408e9ef2e2756a5410b6de (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 7f692b1ddb83ae7ab67d48a1718aeb3e033408b6 (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 026e51ac00810d47a1639b4380e27edccfd5cf25 (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 c6501c12359669a30d92776bc0ea7256c0848161 (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 98f34b36991a56789a953616917d01a9f8843f1e (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 6b56f365ce9bf11ef40aca0f93e1eb5142ab56eb (commit)
via
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 01e8512..6c27ab3 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 11)
-set(CMake_VERSION_TWEAK 20130529
27 matches
Mail list logo
