Hi Bo,
We put together a Wiki page comparing Boost Testing and Google Test in
ITK. It has examples of how to write (ITK) tests in both frameworks and
CTest integration.
http://www.itk.org/Wiki/Proposals:Increasing_ITK_Code_Coverage
-dan
On 7/9/10 6:37 AM, "Bo Thorsen" wrote:
> Hi people,
On 07/12/2010 07:12 PM, Verweij, Arjen wrote:
> As a follow-up: redefining CMAKE_Fortran_LINK_EXECUTABLE to not include
> gets rid of the CMAKE_Fortran_FLAGS.. but perhaps other (useful)
> stuff as well? As a sidetrack I'm starting to wonder what the purpose of
> CMAKE__FLAGS is. The book lists
On 7/12/2010 2:00 PM, Torri, Stephen CIV NSWCDD, W15 wrote:
From: cmake-boun...@cmake.org on behalf of Ryan Pavlik
Sent: Mon 7/12/2010 9:59 AM
To: cmake@cmake.org
Subject: Re: [CMake] CTest examples
I'm been using Boost Test, and I've written a module that lets you add the
executable and the t
On 07/12/2010 03:06 PM, Verweij, Arjen wrote:
> That bit of code is #IFDEF'ed for __APPLE__. I doubt it is causing the
> problem on AIX.
That code is not the cause of the problem, just something that
might be broken by your workaround to the problem. AFAIK there
is nothing that will be broken on
On 07/12/2010 02:47 PM, Verweij, Arjen wrote:
> I will take a looksie and recompile cmake with your suggested fix.
The patch was more of a starting point for discussion among developers.
I think the same problem occurs for shared libraries too, but I see
evidence that it was done on purpose:
h
Brad,
That bit of code is #IFDEF'ed for __APPLE__. I doubt it is causing the problem
on AIX.
Regards,
Arjen
>-Original Message-
>From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
>Of Verweij, Arjen
>Sent: maandag 12 juli 2010 20:47
>To: Brad King
>Cc: cmake@cmake.
> From: cmake-boun...@cmake.org on behalf of Ryan Pavlik
> Sent: Mon 7/12/2010 9:59 AM
> To: cmake@cmake.org
> Subject: Re: [CMake] CTest examples
>
> I'm been using Boost Test, and I've written a module that lets you add the
> executable and the tests (where
> possible, individual named tests) wi
I'm been using Boost Test, and I've written a module that lets you add
the executable and the tests (where possible, individual named tests)
with a single command - see my github repositories for projects that
include this module. http://github.com/rpavlik
On 7/9/10 9:04 PM, Alok Govil wrote
Brad,
That sounds fine, I'm already in the habit of specifying link flags per
language anyway. In fact I will take a looksie and recompile cmake with your
suggested fix.
Regards,
Arjen
>Looking at the implementation I see it gets architecture flags on
>the Mac (-arch and -isysroot), which is c
On 07/12/2010 08:24 PM, Michael Hertling wrote:
> On 07/12/2010 07:06 PM, Jochen Wilhelmy wrote:
>> Hi!
>>
>> adding
>>
>> ${CMAKE_CURRENT_SOURCE_DIR}/VersionInfo.cpp
>> to the source files does not have the desired effect.
>> If I change some file of the target, VersionInfo.cpp
>> does not get rec
Hi Brad,
>It's not *supposed* to do that. Can you produce a minimal project
>that reproduces that behavior?
This is reassuring. I'm probably not able to reproduce it with something small,
but I could try. I would imagine that if it's not supposed to do it, it likely
won't :) Apparently, the pr
On 07/12/2010 07:06 PM, Jochen Wilhelmy wrote:
> Hi!
>
> adding
>
> ${CMAKE_CURRENT_SOURCE_DIR}/VersionInfo.cpp
> to the source files does not have the desired effect.
> If I change some file of the target, VersionInfo.cpp
> does not get recompiled and therefore the current version
> is not incor
On 07/12/2010 01:23 PM, Verweij, Arjen wrote:
> Cmake_copy_f90_mod gets called every time I type make for (as far as
> can tell) every F90 file that provides a module. So for instance I
> change a comment in my main.f, the compile and linktime for the
> executable (4000 ish files) NOT including the
On 07/12/2010 01:25 PM, Verweij, Arjen wrote:
> Can you comment on what other stuff ends up in ?
Looking at the implementation I see it gets architecture flags on
the Mac (-arch and -isysroot), which is consistent with the -m64
type flags I mentioned before. However it looks to me like things
hav
On 7/12/2010 1:20 PM, Brad King wrote:
On 07/12/2010 01:12 PM, Verweij, Arjen wrote:
As a follow-up: redefining CMAKE_Fortran_LINK_EXECUTABLE to not include
gets rid of the CMAKE_Fortran_FLAGS.. but perhaps other (useful)
stuff as well? As a sidetrack I’m starting to wonder what the purpose of
Brad,
Can you comment on what other stuff ends up in ? If it's just
CMAKE__FLAGS, I guess redefining CMAKE__LINK_EXECUTABLE would be a
viable workaround.
Thanks,
Arjen
>-Original Message-
>From: Brad King [mailto:brad.k...@kitware.com]
>Sent: maandag 12 juli 2010 19:20
>To: Verweij, Ar
Hi Brad,
>Actually the copy-f90-mod step is a *feature* to make incremental
>rebuilds faster. It is an optimization for the case that the .f90
>source file that provides a module gets recompiled but the *interface*
>to the module does not change. Many compilers update the timestamp
>on the .mod
On 07/12/2010 01:12 PM, Verweij, Arjen wrote:
> As a follow-up: redefining CMAKE_Fortran_LINK_EXECUTABLE to not include
> gets rid of the CMAKE_Fortran_FLAGS.. but perhaps other (useful)
> stuff as well? As a sidetrack I’m starting to wonder what the purpose of
> CMAKE__FLAGS is. The book lists it
On 07/12/2010 07:51 AM, Verweij, Arjen wrote:
> We’re finding incremental builds to be slow, because the F90 source
> seems to be privy to a processing step known as “cmake_copy_f90_mod”.
>
> While cmake and the compiler race through C/CXX/Fortran(77) source, this
> is not the case for F90. What d
As a follow-up: redefining CMAKE_Fortran_LINK_EXECUTABLE to not include
gets rid of the CMAKE_Fortran_FLAGS.. but perhaps other (useful) stuff as well?
As a sidetrack I'm starting to wonder what the purpose of CMAKE__FLAGS
is. The book lists it as cmake's counterpart of the environment variable
Hi!
adding
${CMAKE_CURRENT_SOURCE_DIR}/VersionInfo.cpp
to the source files does not have the desired effect.
If I change some file of the target, VersionInfo.cpp
does not get recompiled and therefore the current version
is not incorporated into the build.
Therefore I want to recompile it as pre-
Hi,
It seems that in our project the contents of CMAKE__FLAGS is added to the
link line. This causes problems for some of our platforms. Is there a mechanism
to separate language specific compile and link flags out? It would be nice if
you could define CMAKE__COMPILER_FLAGS and CMAKE__LINK_FLAG
On 07/12/2010 04:14 PM, Jochen Wilhelmy wrote:
> Hi!
>
> I'd like to call the c-compiler by hand as pre-link step to compile in
> the current svn version.
>
> on windows i first separate the arguments
>
> separate_arguments(CFLAGS WINDOWS_COMMAND "${CMAKE_CXX_FLAGS}
> ${CMAKE_CXX_FLAGS_DEBUG}
On 07/07/2010 09:44 AM, Michael Wild wrote:
>
> On 7. Jul, 2010, at 9:32 , Michael Hertling wrote:
>
>> On 07/03/2010 01:03 AM, Chris Hillery wrote:
>>> There's a slightly nicer work-around: Change project A's CMakeLists to set
>>> PROJB_OPENCV_LINK as a cache variable, ie, SET(PROJB_OPENCV_LINK
Perhaps I should clarify I bit. It seems my subject line conflated the two
distinct (but tangentially related) issues (perhaps it should have been two
different emails). The subject line I should have used was something like
"quieting output / speeding builds"
Yes, I agree that the number of times
Hi!
I'd like to call the c-compiler by hand as pre-link step to compile in
the current svn version.
on windows i first separate the arguments
separate_arguments(CFLAGS WINDOWS_COMMAND "${CMAKE_CXX_FLAGS}
${CMAKE_CXX_FLAGS_DEBUG} /c")
and then I do
add_custom_command(TARGET MyProject PRE_L
Hi,
We're finding incremental builds to be slow, because the F90 source seems to be
privy to a processing step known as "cmake_copy_f90_mod".
While cmake and the compiler race through C/CXX/Fortran(77) source, this is not
the case for F90. What does "cmake_copy_f90_mod" do? I can hardly find an
Den 09-07-2010 19:03, Eric Noulard skrev:
2010/7/9 Bo Thorsen:
Hi people,
I have converted a set of applications to cmake and cpack, and now have my
eyes set on ctest.
I'd like to hear if someone here has some good advice, or links to good
advice, on how to structure tests. I'm searching for h
Den 10-07-2010 00:05, David Cole skrev:
On Fri, Jul 9, 2010 at 5:54 PM, Chris Hillery mailto:chillery-cm...@lambda.nu>> wrote:
[...]
On Fri, Jul 9, 2010 at 4:37 AM, Bo Thorsen mailto:b...@askmonty.org>> wrote:
[...]
To sum it up, I'm looking for real life advice on what you g
29 matches
Mail list logo
