Hello dear developers, and of course Brad!
11.08.2014, 18:38, Brad King brad.k...@kitware.com:
After some fixes for nightly testing this is now in 'master'...
Thank you that my small contribution is now available for the rest :-)
FYI, if you were to start a new branch and base your changes
On 08/12/2014 02:57 PM, Konstantin Podsvirov wrote:
Update for the last week in one commit:
http://git.podsvirov.pro/?p=kitware/cmake.git;a=commit;h=5ee02291d0c4dde21a4ecb513dd69cbb0157ddf6
Thanks. I revised the commit slightly to not un-do some of my
earlier cleanups (we can't use that
On Mon, Aug 11, 2014 at 11:07:57AM -0400, Brad King wrote:
On 08/08/2014 08:56 AM, Roger Leigh wrote:
On Thu, Aug 07, 2014 at 06:49:28PM +0100, Roger Leigh wrote:
Hi,
I've written a module for finding the details of a ZeroC ICE installation,
attached, which I thought might be of
On Tue, Aug 12, 2014 at 09:08:57PM +0100, Roger Leigh wrote:
On Mon, Aug 11, 2014 at 11:07:57AM -0400, Brad King wrote:
On 08/08/2014 08:56 AM, Roger Leigh wrote:
On Thu, Aug 07, 2014 at 06:49:28PM +0100, Roger Leigh wrote:
3. There is a lot of hard-coded version-specific information
On 11/08/14 18:47, Brad King wrote:
On 08/09/2014 09:46 AM, Marcel Loose wrote:
CMake 2.8.12 introduced the keywords PRIVATE, INTERFACE and PUBLIC, and
immediately deprecated the LINK_INTERFACE_LIBRARIES keyword,
triggering policy warnings CMP0022 and CMP0023.
What is the proper way to get
On 11/08/14 18:47, Brad King wrote:
On 08/09/2014 09:46 AM, Marcel Loose wrote:
CMake 2.8.12 introduced the keywords PRIVATE, INTERFACE and PUBLIC, and
immediately deprecated the LINK_INTERFACE_LIBRARIES keyword,
triggering policy warnings CMP0022 and CMP0023.
What is the proper way to get
From
http://www.cmake.org/cmake/help/v3.0/command/add_custom_command.html :
If COMMAND specifies an executable target (created by ADD_EXECUTABLE)
it will automatically be replaced by the location of the executable
created at build time. Additionally a target-level dependency will be
added so that
Unless it is overridden somewhere else along the way, the following is
used to create the link command line for a C++ executable:
(found in Modules/CMakeCXXInformation.cmake)
if(NOT CMAKE_CXX_LINK_EXECUTABLE)
set(CMAKE_CXX_LINK_EXECUTABLE
CMAKE_CXX_COMPILER FLAGS
On 08/12/2014 03:59 AM, Marcel Loose wrote:
Another problem I faced with policy CMP0022 is that I was unable to
really silence it. Setting the policy to OLD doesn't really work (at
least not in my case), maybe because the cmake_policy() command is
scoped(?).
For CMP0022 and CMP0023 the policy
On 08/12/2014 03:48 AM, Marcel Loose wrote:
That's probably in the CMake 3.0.x docs; CMake 2.8.12 doesn't mention
LINK_PUBLIC and LINK_PRIVATE in the policy documentation. I only read
the following in the docs on target_link_libraries
The LINK_PUBLIC and LINK_PRIVATE modes can be used
Hi David,
Thanks very much for your reply! That was extremely helpful, and will let
several packages document a functional workflow for the future.
On Tue, Aug 12, 2014 at 5:38 AM, David Cole dlrd...@aol.com wrote:
Unless it is overridden somewhere else along the way, the following is
used to
That's a good thought, but unfortunately it didn't pan out. I tried both
styles, and I even tried explicitly mixing styles like this:
BOOST_LIBRARYDIR=C:/local/boost_1_55_0\lib64-msvc-12.0
Or this:
BOOST_LIBRARYDIR=C:\local\boost_1_55_0/lib64-msvc-12.0
And those worked fine.
From:
Greetings,
I tried to move from 2.8 to 3.0.1 today and I'm experiencing an issue with RC
files. Looks like a simple problem but I would be baffled if I'm the first to
experience this so I expect I have some kind of configuration issue. Here is
the offending snippet in the rules.ninja file:
As it turns out, something weirder is going on, and it's not cmake's fault, so
I won't look for a solution here, but I'll describe the problem in case
anyone's interested. *Windows* is not expanding those environment variables.
First, I hacked up the installed version of FindBoost.cmake to spit
On 8/12/2014 12:44 PM, Chris Volpe ARA/SED wrote:
That’s a good thought, but unfortunately it didn’t pan out. I tried both
styles, and I even tried explicitly mixing styles like this:
BOOST_LIBRARYDIR=C:/local/boost_1_55_0\lib64-msvc-12.0
Or this:
Thanks, Bill. As it turns out, the problem appears to be a bug in Windows.
Through experimentation, I have determined a truth about environment variables
that I have yet to be able to find spelled out anywhere: If the type of an
environment variable does not *need* to be Expandable String, then
I only define:
BOOST_ROOT=C:\local\boost_1_56_0
BOOST_LIBRARYDIR=C:\local\boost_1_56_0\lib64-msvc-12.0
and this works Ok.
This will not work:
BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0
If you go to a command prompt and type set you will see that %BOOST_ROOT%
is not expanded.
So this is a
Hi All,
Does anyone know how to remove the primary (first) Administrator of a CDash
instance? All the other users show up with a 'make normal user' and 'remove
user' button but not the original administrator who setup the instance.
Thanks
Matt
--
Powered by www.kitware.com
Please keep
You can always brute force it and go in and remove that user from the
database table with MySQL or phpMyAdmin...
HTH,
David C.
--
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
Yeah I was just worried that since CDash seems to be so fond of this user it
might react badly to their forced departure.
Matt
-Original Message-
From: David Cole [mailto:dlrd...@aol.com]
Sent: Wednesday, 13 August 2014 11:37 AM
To: Bolger, Matt (DPS, Clayton); cmake@cmake.org
I just installed CMake 3.0 and I'm trying out the new generator
expressions for the target_compile_definitions() command.
I am doing this:
target_compile_definitions( ${project_name}
PRIVATE ${general_defs}
PRIVATE $$CONFIG:debug:${debug_defs}
PRIVATE
I think you should be ok... just make another user admin before you do
it, of course. You can always put the user back by brute force, too, if
you discover you need it for something. I'm not aware of anything
special about the user besides its admin-ness.
Good luck, and let us know if you
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 3ff95a9e0cfc1d0f4a9ecfbd4a0845fd6e04b934 (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 e01cb16cdbeac38c1b23e651137efc29116d2c48 (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 f995368714dcc9d9d770b3a3c4f7163abda58027 (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 354c792c9de5759a4484dc157a206e06012e83c6 (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, release has been updated
via 8db3c79f63841e8cabd7e84968da72522f656cb1 (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 755891c3d92b684e7884ccb3016e5a1da89bbbde (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 971b990718b75dd8848e795a07294d8f7594b9a7 (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 7365a9fe929c935a194987d3a4a68aff77129a2b (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 3e510c4e348f3d029cf56f3774eec97b609aa544 (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 6b923df4c355496816aefbe5793d892d4ac907d1 (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 561267f15216de102807a42e043b9aebe1ea5388 (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 d905333fad73754b594872e67e0e979f31a1b0ab (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 e0d54b040c808bc7337e01ade615f01f6497a73b (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 3f66f2fbe8f6c27d4bf541fa32c91582f7078174 (commit)
via
20140812)
+set(CMake_VERSION_PATCH 20140813)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
37 matches
Mail list logo
