Hello,
I am still trying to get ctest working on our directory structure.
Thanks to the bugfix in 2.8, running the test itself works fine.
However, there seems to be an issue with code coverage testing.
Assuming the following directory structure:
projects/
libFoo/
cmake
On Tuesday 10 November 2009 19:30:25 Alan W. Irwin wrote:
On 2009-11-10 17:34-0500 lists_r...@lavabit.com wrote:
How does one ensure that the appropriate scanner is run to obtain
implicit dependencies via IMPLICIT_DEPENDS? In the following example,
the 'drop' target depends on dummy.cc
Hi,
On Sun, Nov 8, 2009 at 5:04 AM, Bill Hoffman bill.hoff...@kitware.comwrote:
Daniel Dunbar wrote:
Hi Bill,
Thanks for the reply.
The uses I'm seeing aren't on external targets, they are for internal
libraries which are built during the build. Is this the same problem?
Pretty much
Jeroen Dierckx wrote:
I noticed that libraries are put into the link flags. They don't show up
in the Linked Libraries list of the target's info. Could it be that
everything works correctly if we could libraries there? I think XCode
does some extra logic in that case, as opposed to
Hello,
CTEST_CUSTOM_TESTS_IGNORE
Having a CTestCusom.cmake file works fine when running
make test
ctest
see:
http://pastebin.ca/1666592
But it's content is ignored when the build is scripted via ctest -S.
This is the log for ctest --debug -VV -S
http://pastebin.ca/1666597
as you can
This is a screenshot
http://imagebin.ca/view/TtO6Iu.html
of an eclipse gdb session, which show that the already populated
CustomTestsIgnore
vector is cleared.
I don't know if this is the source of the bug, since it should be refilled in
cmCTest::PopulateCustomVector(..)
but the cmMakefile
Ok, it works like this:
cmCTest::ReadCustomConfigurationFileTree searches for
CTestCustom.(cmake|ctest) and reads it. If found, this code the inte
same method
if ( found )
{
cmCTest::t_TestingHandlers::iterator it;
for ( it = this-TestingHandlers.begin();
it !=
James C. Sutherland wrote:
Thanks. To be clear, it only works if I use
set( ExprLib_LIBRARIES @TPL_LIBRARIES@ )
because otherwise I have no way of propagating the dependents of
ExprLib downstream. It is true that CMake will add the ExprLib
library as a target that can be used
On Nov 11, 2009, at 9:05 AM, Brad King wrote:
James C. Sutherland wrote:
Thanks. To be clear, it only works if I use
set( ExprLib_LIBRARIES @TPL_LIBRARIES@ )
because otherwise I have no way of propagating the dependents of
ExprLib downstream. It is true that CMake will add the
Well well...
After I did this
{{{
--- Source/CTest/cmCTestTestHandler.cxx 25 Jun 2008 13:51:45 - 1.68.2.3
+++ Source/CTest/cmCTestTestHandler.cxx 11 Nov 2009 18:38:38 -
@@ -413,7 +413,7 @@
this-TestResults.clear();
- this-CustomTestsIgnore.clear();
+
I'm trying to figure out in what scenarios one might use import/export
verses using the new ExternalProject_add.
...
When would one pick one method over the other?
I haven't used import/export, and don't know about them. I am using
ExternalProject to build self-contained, wholly-separate
CMake 2.8.0 RC 7 is now ready for people to try. Due to a few missed
files and a bug in ctest that was not fixed on the branch, I have made
an RC 7. Please let me know if you find any serious regressions. I
still plan to release 2.8.0 final this week. Thanks.
You can find the source and
I am using the macports version of python on a Snow Leopard computer, and
using cmake to build a cross-platform extension to it.
include(FindPythonInterp)
include(FindPythonLibs )
However, while cmake identified the correct interpreter in /opt/local/bin,
it tries to link against the wrong
Add -F /opt/local/Library/Frameworks” to your compilation flags or add this
line to your .bash_profile:
export DYLD_FRAMEWORK_PATH=/opt/local/Library/Frameworks
On Nov 11, 2009, at 4:15 PM, Celil Rufat wrote:
I am using the macports version of python on a Snow Leopard computer, and
using
Jed Brown wrote:
Mark Moll wrote:
Add -F /opt/local/Library/Frameworks to your compilation flags or
add this line to your .bash_profile:
You should never add the -F to the CMake flags, just use the full path
to the framework dir in either an include or a link library and CMake
will add the
I'm having a problem when I use ${CMAKE_CFG_INTDIR} as part of my
LIBRARY_OUTPUT_DIRECTORY when generating Xcode projects. It seems that
cmake properly puts quotes around the path when I have a dash in the path,
but does not put them there when I don't. Here's what I have:
set_target_properties
I mixed up the ordering of the examples in my last email. I said that the
first one works great. I really meant that the second one works great
(where the Xcode project file has quotes around the path) and the first one
doesn't work (where there are no quotes around the resulting path). Sorry
For the last day or so I have tried to compile a project(RobWork) for Visual
Studio 2008 using Cmake.
But my problem is that Cmake claims i can't find Boost dependencies.
I have been googling the problem on the net, but the only answer I could
find was that FindBost.cmake was the problem, but
Usually when I build Boost on Windows I use the
--prefix=C:\Path\To\Boost and the install target instead of the
stage target.
Then I set BOOST_ROOT to what ever I set the --prefix argument to.
That seems to always work.
And to try this out you will need a clean RobWork build directory. So,
to
Hi,
I am using CMake 2.6 and I would like to be able to decompress bz2
files. Is it possible to add bz2 compression to the tar command (or
even better is it already there?). I was hoping to do something like
cmake -E tar xjf my_really_cool_source_files.tar.bz2
I have looked but didn't
These seem like bugs to me. I'm pretty sure you're going to have similar
luck across many find modules in CMake, however. I don't think static
linking is that widely tested, unfortunately.
For libxml2's dependency on pthread you should be able to use FindThreads or
FindPthreads. I'm not sure
21 matches
Mail list logo
