The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13160
==
Reported By:Andreas Roth
Assigned To:
On Mon, Apr 23, 2012 at 3:52 PM, Bill Hoffman bill.hoff...@kitware.com wrote:
On 4/21/2012 7:37 AM, Peter Kümmel wrote:
Great! Is this the step which will be dropped when the /fast target is
build?
Peter
No, that drops building all the dependent targets.
So, would it be possible to
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13161
==
Reported By:Frank Glinka
Assigned To:
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13162
==
Reported By:Dave Abrahams
Assigned To:
Hi everyone,
I'm using windows 7 (64). I'm trying to determine the python installation
using cmake.
The problem is that cmake only exists as a 32 bit application. As a
consequence, it has only access to the 32 bit registry entries (WOW64). I
have installed python as a 64 bit application, which is
Hi everyone,
I'm using windows 7 (64). I'm trying to determine the python installation
using cmake.
The problem is that cmake only exists as a 32 bit application. As a
consequence, it has only access to the 32 bit registry entries (WOW64). I
have installed python as a 64 bit application,
Hi All!
I have a problem with target_link_libraries. It can't link with shared
libraries not from directory listed in LD_LIBRARY_PATH.
1. When I try to link shared library with the full path obtained from
find_library, my library is passed to gcc without -l option as ordinary
object file.
On 04/20/2012 12:36 PM, Eric Noulard wrote:
Nope, it would break backward compatibility, you can dig the ML
for discussion about that issue.
My opinion is that building in-source is a bad habit that ought to be
discouraged but the fact is,
this is not currently easy to enforce out-of-source:
You should just get used to using shorter paths on the embarrassing OS.
This is an early warning sign for you that your end users will also
encounter these problems as they install your program on their systems in
non-short root paths...
You can ignore it if you wish, but the fact remains that
On 04/23/2012 01:32 PM, David Cole wrote:
You should just get used to using shorter paths on the embarrassing OS.
This is an early warning sign for you that your end users will also
encounter these problems as they install your program on their systems
in non-short root paths...
You can
Am 23.04.2012 10:45, schrieb Jörg F. Unger:
Hi everyone,
...
Any ideas how to circumvent these problems? Or is there a way to build a
64 bit cmake?
You can build 64 bit cmake with the 32 bit version and at least the
mingw-w64 compiler, it probably builds using visual studio too.
I haven't
Hi,
On Mon, Apr 23, 2012 at 13:24, Vyacheslav Karamov ubuntul...@yandex.ruwrote:
Hi All!
I have a problem with target_link_libraries. It can't link with shared
libraries not from directory listed in LD_LIBRARY_PATH.
1. When I try to link shared library with the full path obtained from
Hi!
I just find the solution. The problem was in order how libraries were
specified.
target_link_libraries(${lib_name}
general rt
general dl
general pthread
debug ${do_scoring_debug}
optimized ${do_scoring}
general ${spinx}
general ${cblas}
general ${atlas}
)
23.04.2012 16:28, Andreas
On Mon, Apr 23, 2012 at 4:45 AM, Jörg F. Unger
joergfun...@googlemail.com wrote:
Hi everyone,
I'm using windows 7 (64). I'm trying to determine the python installation
using cmake.
The problem is that cmake only exists as a 32 bit application. As a
consequence, it has only access to the 32
Hi!
I just find the solution. The problem was in order how libraries were
specified.
target_link_libraries(${lib_name}
general rt
general dl
general pthread
debug ${do_scoring_debug}
optimized ${do_scoring}
general ${spinx}
general ${cblas}
general ${atlas}
)
You don't need the
2012/4/23 Brad King brad.k...@kitware.com
On Mon, Apr 23, 2012 at 4:45 AM, Jörg F. Unger
joergfun...@googlemail.com wrote:
Hi everyone,
I'm using windows 7 (64). I'm trying to determine the python installation
using cmake.
The problem is that cmake only exists as a 32 bit application.
On Mon, Apr 23, 2012 at 8:38 AM, Andrea Crotti andrea.crott...@gmail.comwrote:
On 04/23/2012 01:32 PM, David Cole wrote:
You should just get used to using shorter paths on the embarrassing OS.
This is an early warning sign for you that your end users will also
encounter these problems as
Hi,
I have a cmake project with some weird requirements:
It uses an external project that uses autotools. I have the other project's
source tree unpacked in a subdirectory. During a build of my project, I want to
run configure with some options, make, and make install in the subdirectory,
Hi David,
Yes, I should have time somewhere this week...
Johannes
On Thursday, April 19, 2012 11:20:48 PM David Cole wrote:
Hi Johannes,
Time to update again, this time for CMake 2.8.8.
Do you have time to do the update again in the next week or two?
Thanks,
David
On Thu, Jan 5,
Hi,
Another question:
I want to be able to run my tests with and without valgrind. A few tests should
always run without valgrind, and a few others should run with helgrind and
still others with drd.
Currently, I have a function add_memcheck_test that invokes add_test twice and
creates
Hi,
You can have a look at the ExternalProject module:
$ cmake --help-module ExternalProject
Cheers,
-Nico
On Mon, Apr 23, 2012 at 5:10 PM, Leif Walsh leif.wa...@gmail.com wrote:
Hi,
I have a cmake project with some weird requirements:
It uses an external project that uses autotools. I
I am wondering what a good rule of thumb is when upgrading CMake. Should I
delete my cache after each upgrade? I'm on Windows.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the
On Mon, Apr 23, 2012 at 1:46 PM, Robert Dailey rcdailey.li...@gmail.com wrote:
I am wondering what a good rule of thumb is when upgrading CMake. Should I
delete my cache after each upgrade? I'm on Windows.
--
I never ever do that on windows. And I have done 100s of builds with
CMake and many
A good rule of thumb is to try just upgrading CMake and running it on
existing build trees. It's obviously quicker than a re-configure from
scratch.
But then, before complaining about something not working, try it in a fresh
build tree first, then if it's still wrong, complain. :-)
It's rare,
A good rule of thumb is to try just upgrading CMake and running it on
existing build trees. It's obviously quicker than a re-configure from
scratch.
But then, before complaining about something not working, try it in a fresh
build tree first, then if it's still wrong, complain. :-)
It's
cmake: 2.8.6
gcc/g++: 4.4.6-3
Red Hate Enterprise Linux 6.2
I follow the instructions here: http://www.cmake.org/Wiki/CTest/Coverage
And I have 2 different dashboards that report zero coverage:
http://testing.psychiatry.uiowa.edu/CDash/index.php?project=BRAINSStandalone
On 2012-04-23 14:13-0400 David Cole wrote:
A good rule of thumb is to try just upgrading CMake and running it on existing
build trees. It's obviously quicker than a re-configure
from scratch.
But then, before complaining about something not working, try it in a fresh
build tree first, then
Hi Stefan,
one solution I can think about is overwriting the install() command
before you traverse into these subdirectories and restoring the
default CMake behavior afterwards, i.e., something like
# overwrite install() command with a dummy macro that is a nop
macro (install)
endmacro ()
#
Hi Mathias,
I simply guess that the reason for COMPILE_DEFINITIONS not including
-pedantic is, that you actually use add_definitions() for something
what it is not really intended for, i.e., the addition of compiler
flags other than those which define preprocessor macros... maybe
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 36ae3659c2d2cf4f7917f0ab9d5eaa5a455c0b55 (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 b9fe606aff25f7940082e60bedb0b1cd28176aaa (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 fc1af7e4b79ecd4d76d78d4535fa45fc5be0fd09 (commit)
via
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 2c0122c..67f3d2f 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 8)
-SET(CMake_VERSION_TWEAK 20120423
33 matches
Mail list logo
