Thanks, this worked perfectly.
On Apr 23, 2012, at 11:45 AM, Nicolas Desprès wrote:
> 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 wrote:
>> Hi,
>>
>> I have a cmake proj
I have some tests that are expected to abort. Imagine something like:
#include
int main(void) {
assert(0);
return 0;
}
If I put this test into cmake and set the test's property WILL_FAIL to TRUE, it
fails with "Exception: Other". I'm writing C, so I don't have exceptions, but
cmake s
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
add_definitions()
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 ()
# conf
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 if
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
http://testing.psychiatry
> 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. :-)
>
>
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, alt
On Mon, Apr 23, 2012 at 1:46 PM, Robert Dailey 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 upgrades since CMake 2.
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
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 wrote:
> Hi,
>
> I have a cmake project with some weird requirements:
>
> It uses an external project that uses autotools. I have the other proj
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 targe
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 Th
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,
then
On Mon, Apr 23, 2012 at 8:38 AM, Andrea Crotti wrote:
> 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
2012/4/23 Brad King
> On Mon, Apr 23, 2012 at 4:45 AM, Jörg F. Unger
> 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 acces
> 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
On Mon, Apr 23, 2012 at 4:45 AM, Jörg F. Unger
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 bit registry entries (WO
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 Pakulat
Hi,
On Mon, Apr 23, 2012 at 13:24, Vyacheslav Karamov wrote:
> 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 l
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
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 ig
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/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:
h
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.
2
> 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 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 n
27 matches
Mail list logo
