[CMake] find_library() and mark_as_advanced()
Hi there,
I have modified FindZLIB.cmake and FindPNG.cmake, because I want to specify
a separate release and debug library for MSVC to link to.
The problem is, my libraries are not in any standard place.
I want to use cmake-gui, run cmake and punch in exactly where these
libraries live.
So I have a call in FindPNG, like this:
find_library(PNG_LIBRARY_RELEASE NAMES ${PNG_NAMES_RELEASE} )
which it will not find.
at the bottom, there is:
mark_as_advanced(PNG_PNG_INCLUDE_DIR PNG_LIBRARY PNG_LIBRARY_RELEASE
PNG_LIBRARY_DEBUG)
My problem is, PNG_LIBRARY_DEBUG/RELEASE do NOT appear in cmake-gui.
Only PNG_PNG_INCLUDE_DIR and PNG_LIBRARY show up.
Is this because if Find_Target() doesn't find anything, it does not define
the variable at all?
This creates a problem. If find_target doesn't find the target, the
variable is not defined, and thus the user isn't given the chance to input
the correct location.
Note that PNG_LIBRARY is not good enough, because you can't specify a set
of optimized/debug libraries in the slot.
My only choice seems to be to hack the cmake files to define the
PNG_RELEASE_LIBRARY variable. Which is not ideal, because I'm compiling
VTK, this is not my own project, so I'll have to maintain a patch just for
this hack.
thanks,
Paul
--
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 CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Link flags not applied to static library
That bug is regarding CMAKE_STATIC_LINKER_FLAGS
What about this bug report:
http://www.cmake.org/Bug/view.php?id=12295
which is related to STATIC_LIBRARY_FLAGS
On 1 December 2012 16:00, Timothy J. Arrington sse...@gmail.com wrote:
The bug is already reported for quite a while:
http://public.kitware.com/Bug/view.php?id=10094, but so far, hasn't
been fixed.
2012/11/28 Paul Harris harris...@gmail.com:
Hi,
I set this:
set (STATIC_LIBRARY_FLAGS_RELWITHDEBINFO
${STATIC_LIBRARY_FLAGS_RELWITHDEBINFO} /LTCG)
and it didn't seem to work. MSVC still has no LTCG flag set for any of
my
static libraries.
does this feature work?
cheers,
Paul
On 23 June 2011 01:02, Ben Medina ben.med...@gmail.com wrote:
So that the answer stays on the list:
One must use the STATIC_LIBRARY_FLAGS property, rather than
LINK_FLAGS, for static libraries.
On Tue, Jun 21, 2011 at 3:12 PM, Ben Medina ben.med...@gmail.com
wrote:
Since I got no feedback, I assume it's a bug. I've filed it here:
0012295: LINK_FLAGS_RELEASE has no effect on static libraries for MSVC
generators
http://www.cmake.org/Bug/view.php?id=12295
On Mon, Jun 13, 2011 at 11:50 AM, Ben Medina ben.med...@gmail.com
wrote:
Hello all,
I'm using CMake 2.8.4 and am seeing an odd differenc between static
and shared libraries in regard to the LINK_FLAGS property. In
particular, I'm enabling Whole program optimization in Visual
Studio
2010, which is done by add /GL as a compiler flag and /LTCG as a
linker flag for the release configuration. However, the link flag is
not used for static libraries, leading to a build warning about
compiling with /GL but linking without /LTCG.
Here's an example:
cmake_minimum_required (VERSION 2.8)
project (link_test)
set (CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE} /GL)
add_library (static_test STATIC a.cpp)
set_target_properties (
static_test
PROPERTIES
LINK_FLAGS_RELEASE /LTCG
)
add_library (shared_test SHARED a.cpp)
set_target_properties (
shared_test
PROPERTIES
LINK_FLAGS_RELEASE /LTCG
)
Just add an empty file called a.cpp to the directory, then build the
whole project in release configuration. You'll get a warning like
this
for the static_test library:
2 a.obj : MSIL .netmodule or module compiled with /GL found;
restarting link with /LTCG; add /LTCG to the link command line to
improve
Why is CMake not applying LINK_FLAGS_RELEASE to the static library?
Thanks,
Ben
___
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 CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
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 CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
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 CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Link flags not applied to static library
Hi,
I set this:
set (STATIC_LIBRARY_FLAGS_RELWITHDEBINFO
${STATIC_LIBRARY_FLAGS_RELWITHDEBINFO} /LTCG)
and it didn't seem to work. MSVC still has no LTCG flag set for any of my
static libraries.
does this feature work?
cheers,
Paul
On 23 June 2011 01:02, Ben Medina ben.med...@gmail.com wrote:
So that the answer stays on the list:
One must use the STATIC_LIBRARY_FLAGS property, rather than
LINK_FLAGS, for static libraries.
On Tue, Jun 21, 2011 at 3:12 PM, Ben Medina ben.med...@gmail.com wrote:
Since I got no feedback, I assume it's a bug. I've filed it here:
0012295: LINK_FLAGS_RELEASE has no effect on static libraries for MSVC
generators
http://www.cmake.org/Bug/view.php?id=12295
On Mon, Jun 13, 2011 at 11:50 AM, Ben Medina ben.med...@gmail.com
wrote:
Hello all,
I'm using CMake 2.8.4 and am seeing an odd differenc between static
and shared libraries in regard to the LINK_FLAGS property. In
particular, I'm enabling Whole program optimization in Visual Studio
2010, which is done by add /GL as a compiler flag and /LTCG as a
linker flag for the release configuration. However, the link flag is
not used for static libraries, leading to a build warning about
compiling with /GL but linking without /LTCG.
Here's an example:
cmake_minimum_required (VERSION 2.8)
project (link_test)
set (CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE} /GL)
add_library (static_test STATIC a.cpp)
set_target_properties (
static_test
PROPERTIES
LINK_FLAGS_RELEASE /LTCG
)
add_library (shared_test SHARED a.cpp)
set_target_properties (
shared_test
PROPERTIES
LINK_FLAGS_RELEASE /LTCG
)
Just add an empty file called a.cpp to the directory, then build the
whole project in release configuration. You'll get a warning like this
for the static_test library:
2 a.obj : MSIL .netmodule or module compiled with /GL found;
restarting link with /LTCG; add /LTCG to the link command line to
improve
Why is CMake not applying LINK_FLAGS_RELEASE to the static library?
Thanks,
Ben
___
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 CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
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 CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Valgrind fails but ctest doesn't notice
Hi, When I run valgrind on a test directly, I see this: $ valgrind test_array ==30643== Memcheck, a memory error detector ==30643== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==30643== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==30643== Command: test_array ==30643== ==30643== Conditional jump or move depends on uninitialised value(s) ==30643==at 0x402291: test_misc (in test_array) ==30643==by 0x404A53: run_tests (in test_array) ==30643==by 0x402257: main (in test_array) ==30643== ==30643== ==30643== HEAP SUMMARY: ==30643== in use at exit: 0 bytes in 0 blocks ==30643== total heap usage: 70 allocs, 70 frees, 6,647 bytes allocated ==30643== ==30643== All heap blocks were freed -- no leaks are possible ==30643== ==30643== For counts of detected and suppressed errors, rerun with: -v ==30643== Use --track-origins=yes to see where uninitialised values come from ==30643== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4) (note the bug I put in on purpose) When ctest runs, it just says passed. Surely it should flag a problem? What am I doing wrong? thanks, Paul -- 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 CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] symstore
Hi, http://www.stackhash.com/blog/post/Setting-up-a-Symbol-Server.aspx I read this blog and thought it would be great to have cmake generate a SYMSTORE project in addition to the INSTALL project, which would add the pdb files to the symstore area. I googled and haven't heard anything about it anywhere else, in relation to cmake. How do cmake users manage debugging minidumps from users? thanks Paul ___ 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 CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On 11 July 2010 20:36, Michael Hertling mhertl...@online.de wrote:
On 07/10/2010 06:54 PM, Paul Harris wrote:
On 9 July 2010 22:39, Michael Wild them...@gmail.com wrote:
On 9. Jul, 2010, at 15:48 , Michael Hertling wrote:
On 07/08/2010 09:47 AM, Paul Harris wrote:
On 8 July 2010 15:31, Michael Wild them...@gmail.com wrote:
On 8. Jul, 2010, at 7:25 , Paul Harris wrote:
On 8 July 2010 12:56, Michael Wild them...@gmail.com wrote:
On 8. Jul, 2010, at 4:40 , Paul Harris wrote:
On 7 July 2010 23:05, Michael Wild them...@gmail.com wrote:
On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
Hi all,
I have looked and can't find the answer, so I turn to the list.
I have a CMakeLists.txt and a subdirectory called utils, which
also
has
its
own CMakeLists.txt
In the parent CML.txt, I have something like:
ENABLE_TESTING()
add_subdirectory(utils)
In my utils CML.txt, I have
ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
Simplify this to
ADD_TEST(unit_1 unit_1)
CMake will figure out by itself that unit_1 is a target and
invoke
the
executable correctly (your code would break for
multi-configuration
IDE
generators).
This does not work for me. If I do not have the
EXECUTABLE_OUTPUT_PATH
in
add_test, I get a message like this when i run make test
(shortened
for
brevity):
1/ 1 Testing unit_string_numeric_utils Could not find
executable
unit_string_numeric_utils
Looked in the following places:
unit_string_numeric_utils
unit_string_numeric_utils
Release/unit_string_numeric_utils
Release/unit_string_numeric_utils
Mmmh, works fine for me:
-8-
cmake_minimum_required(VERSION 2.8)
project(tmp)
enable_testing()
add_executable(unit1 unit1.cpp)
add_test(unit1 unit1)
-8-
Where unit1.cpp is just a simple hello-world program. Running it:
snip
My project is a lot bigger than a hello-world program. It has
subdirectories for a start, and I do things like
SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL
Single
output directory for building all executables.)
I'm not sure at which point things stop working, do you want me to
try
and
build a test-case?
You are right, it seems that the documentation is misleading (or IMHO
outright wrong). This, however, works for me and is safe:
add_test(NAME unit1 COMMAND $TARGET_FILE:unit1)
Note that NAME and COMMAND are required for this to work.
BTW: EXECUTABLE_OUTPUT_PATH is deprecated, you should use
CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.
I changed EXE to that CMAKE RUNTIME thing, thanks.
That NAME/COMMAND thing doesn't work for me at all. Can't find the
binary
without the runtime output path explicitly added.
This is what I tried:
In parent CMakeLists.txt
ENABLE_TESTING()
set (CMAKE_TEST_COMMAND ctest -V)
function (add_unit_test name)
if(NOT TARGET ${name})
add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
endif()
add_executable(${name} ${ARGN})
add_test(NAME ${name} COMMAND $TARGET_FILE:${name})
add_dependencies(check ${name})
endfunction()
in subdirectory CMakeLists.txt
add_unit_test(unit_string_numeric_utils
units/unit_string_numeric_utils.cpp
string_numeric_utils.cpp)
Could you detect manually where the binary in question gets written
to, and post ctest's output with the complaint about not finding it,
and perhaps you could also post a minimal CMakeLists.txt file which
demonstrates this issue along with the output of make VERBOSE=1?
Regards,
Michael
I suspect he's using a pre-2.8 version of CMake. I confirmed that
add_test
only resolves executable target names if used with NAME and COMMAND, and
this signature was introduced in 2.8.
I'm using 2.8.1
Michael Hertling - do you still want me to follow up as you asked?
Yes, of course, if the problem still persists. Until now, I haven't
managed to let CTest miss an executable previously built by CMake,
i.e. ADD_TEST(NAME ... COMMAND ...) always worked well for me.
Regards,
Michael
Ok first thing: I had two cmakes on my system, one was 2.8.1, and an older
2.6.3 that snuck in through an incorrect script of mine.
Second thing: the TARGET_FILE thing works. But the usual add_test(name
command) does not.
Ok here we go, minimal test case is attached (uses cmake 2.8.1),
procedure:
save all files into /tmp/test
mkdir /tmp/build
cd /tmp/build
cmake ../test/ make VERBOSE=1 check
results of that are attached as result.txt
thanks
Paul
project (unit_1 CXX)
cmake_minimum_required(VERSION 2.8.1)
enable_testing()
add_custom_target (check COMMAND ${CMAKE_CTEST_COMMAND})
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL )
add_executable(unit_1 unit_1.cpp)
add_test(unit_1 unit_1)
# this works add_test(NAME unit_1
Re: [CMake] building tests
On 9 July 2010 22:39, Michael Wild them...@gmail.com wrote:
On 9. Jul, 2010, at 15:48 , Michael Hertling wrote:
On 07/08/2010 09:47 AM, Paul Harris wrote:
On 8 July 2010 15:31, Michael Wild them...@gmail.com wrote:
On 8. Jul, 2010, at 7:25 , Paul Harris wrote:
On 8 July 2010 12:56, Michael Wild them...@gmail.com wrote:
On 8. Jul, 2010, at 4:40 , Paul Harris wrote:
On 7 July 2010 23:05, Michael Wild them...@gmail.com wrote:
On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
Hi all,
I have looked and can't find the answer, so I turn to the list.
I have a CMakeLists.txt and a subdirectory called utils, which
also
has
its
own CMakeLists.txt
In the parent CML.txt, I have something like:
ENABLE_TESTING()
add_subdirectory(utils)
In my utils CML.txt, I have
ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
Simplify this to
ADD_TEST(unit_1 unit_1)
CMake will figure out by itself that unit_1 is a target and invoke
the
executable correctly (your code would break for multi-configuration
IDE
generators).
This does not work for me. If I do not have the
EXECUTABLE_OUTPUT_PATH
in
add_test, I get a message like this when i run make test
(shortened
for
brevity):
1/ 1 Testing unit_string_numeric_utils Could not find
executable
unit_string_numeric_utils
Looked in the following places:
unit_string_numeric_utils
unit_string_numeric_utils
Release/unit_string_numeric_utils
Release/unit_string_numeric_utils
Mmmh, works fine for me:
-8-
cmake_minimum_required(VERSION 2.8)
project(tmp)
enable_testing()
add_executable(unit1 unit1.cpp)
add_test(unit1 unit1)
-8-
Where unit1.cpp is just a simple hello-world program. Running it:
snip
My project is a lot bigger than a hello-world program. It has
subdirectories for a start, and I do things like
SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL
Single
output directory for building all executables.)
I'm not sure at which point things stop working, do you want me to try
and
build a test-case?
You are right, it seems that the documentation is misleading (or IMHO
outright wrong). This, however, works for me and is safe:
add_test(NAME unit1 COMMAND $TARGET_FILE:unit1)
Note that NAME and COMMAND are required for this to work.
BTW: EXECUTABLE_OUTPUT_PATH is deprecated, you should use
CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.
I changed EXE to that CMAKE RUNTIME thing, thanks.
That NAME/COMMAND thing doesn't work for me at all. Can't find the
binary
without the runtime output path explicitly added.
This is what I tried:
In parent CMakeLists.txt
ENABLE_TESTING()
set (CMAKE_TEST_COMMAND ctest -V)
function (add_unit_test name)
if(NOT TARGET ${name})
add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
endif()
add_executable(${name} ${ARGN})
add_test(NAME ${name} COMMAND $TARGET_FILE:${name})
add_dependencies(check ${name})
endfunction()
in subdirectory CMakeLists.txt
add_unit_test(unit_string_numeric_utils
units/unit_string_numeric_utils.cpp
string_numeric_utils.cpp)
Could you detect manually where the binary in question gets written
to, and post ctest's output with the complaint about not finding it,
and perhaps you could also post a minimal CMakeLists.txt file which
demonstrates this issue along with the output of make VERBOSE=1?
Regards,
Michael
I suspect he's using a pre-2.8 version of CMake. I confirmed that add_test
only resolves executable target names if used with NAME and COMMAND, and
this signature was introduced in 2.8.
I'm using 2.8.1
Michael Hertling - do you still want me to follow up as you asked?
___
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 CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On 8 July 2010 15:31, Michael Wild them...@gmail.com wrote:
On 8. Jul, 2010, at 7:25 , Paul Harris wrote:
On 8 July 2010 12:56, Michael Wild them...@gmail.com wrote:
On 8. Jul, 2010, at 4:40 , Paul Harris wrote:
On 7 July 2010 23:05, Michael Wild them...@gmail.com wrote:
On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
Hi all,
I have looked and can't find the answer, so I turn to the list.
I have a CMakeLists.txt and a subdirectory called utils, which also
has
its
own CMakeLists.txt
In the parent CML.txt, I have something like:
ENABLE_TESTING()
add_subdirectory(utils)
In my utils CML.txt, I have
ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
Simplify this to
ADD_TEST(unit_1 unit_1)
CMake will figure out by itself that unit_1 is a target and invoke the
executable correctly (your code would break for multi-configuration
IDE
generators).
This does not work for me. If I do not have the EXECUTABLE_OUTPUT_PATH
in
add_test, I get a message like this when i run make test (shortened
for
brevity):
1/ 1 Testing unit_string_numeric_utils Could not find executable
unit_string_numeric_utils
Looked in the following places:
unit_string_numeric_utils
unit_string_numeric_utils
Release/unit_string_numeric_utils
Release/unit_string_numeric_utils
Mmmh, works fine for me:
-8-
cmake_minimum_required(VERSION 2.8)
project(tmp)
enable_testing()
add_executable(unit1 unit1.cpp)
add_test(unit1 unit1)
-8-
Where unit1.cpp is just a simple hello-world program. Running it:
snip
My project is a lot bigger than a hello-world program. It has
subdirectories for a start, and I do things like
SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL
Single
output directory for building all executables.)
I'm not sure at which point things stop working, do you want me to try
and
build a test-case?
You are right, it seems that the documentation is misleading (or IMHO
outright wrong). This, however, works for me and is safe:
add_test(NAME unit1 COMMAND $TARGET_FILE:unit1)
Note that NAME and COMMAND are required for this to work.
BTW: EXECUTABLE_OUTPUT_PATH is deprecated, you should use
CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.
I changed EXE to that CMAKE RUNTIME thing, thanks.
That NAME/COMMAND thing doesn't work for me at all. Can't find the binary
without the runtime output path explicitly added.
This is what I tried:
In parent CMakeLists.txt
ENABLE_TESTING()
set (CMAKE_TEST_COMMAND ctest -V)
function (add_unit_test name)
if(NOT TARGET ${name})
add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
endif()
add_executable(${name} ${ARGN})
add_test(NAME ${name} COMMAND $TARGET_FILE:${name})
add_dependencies(check ${name})
endfunction()
in subdirectory CMakeLists.txt
add_unit_test(unit_string_numeric_utils units/unit_string_numeric_utils.cpp
string_numeric_utils.cpp)
___
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 CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] building tests
Hi all,
I have looked and can't find the answer, so I turn to the list.
I have a CMakeLists.txt and a subdirectory called utils, which also has its
own CMakeLists.txt
In the parent CML.txt, I have something like:
ENABLE_TESTING()
add_subdirectory(utils)
In my utils CML.txt, I have
ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
When I run make test on the command line, it will only run the tests, it
doesn't build my tests.
When I want to do some work and test it, I would like to do something like
make build_run_tests
and have it automatically build ALL of my unit tests, and then run ALL of my
unit tests.
But there doesn't seem to be any way other than something like
make unit_1 unit_2 unit_3 make test
Which is very difficult to do, as the actual names of my unit tests are much
longer, eg unit_string_numeric_utils
I tried doing cmake --build-and-test but that seems to demand that I also
tell it what the targets are too!
I did the following hack,
in parent CML.txt, it now reads:
ENABLE_TESTING()
set (UNIT_TESTS)
add_subdirectory(utils)
add_custom_target (build_tests ALL DEPENDS ${UNIT_TESTS})
add_custom_target (build_run_tests ALL DEPENDS ${UNIT_TESTS} test)
and in utils/CML.txt it now reads:
ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
SET (UNIT_TESTS ${UNIT_TESTS} unit_1 PARENT_SCOPE)
so I am MANUALLY adding every unit test into UNIT_TESTS variable, and then
I add a custom target to build them all.
But you can see that my attempt to make build_run_tests failed, as I can't
seem to build the 'test' subproject directly.
This hack is very verbose, I have to add
SET (UNIT_TESTS ${UNIT_TESTS} unit_xyz PARENT_SCOPE)
for EVERY unit test I write.
WHY is it so annoying to do such a seemingly simple thing?
thanks
Paul
___
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 CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On 7 July 2010 23:05, Michael Wild them...@gmail.com wrote:
On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
Hi all,
I have looked and can't find the answer, so I turn to the list.
I have a CMakeLists.txt and a subdirectory called utils, which also has
its
own CMakeLists.txt
In the parent CML.txt, I have something like:
ENABLE_TESTING()
add_subdirectory(utils)
In my utils CML.txt, I have
ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
Simplify this to
ADD_TEST(unit_1 unit_1)
CMake will figure out by itself that unit_1 is a target and invoke the
executable correctly (your code would break for multi-configuration IDE
generators).
This does not work for me. If I do not have the EXECUTABLE_OUTPUT_PATH in
add_test, I get a message like this when i run make test (shortened for
brevity):
1/ 1 Testing unit_string_numeric_utils Could not find executable
unit_string_numeric_utils
Looked in the following places:
unit_string_numeric_utils
unit_string_numeric_utils
Release/unit_string_numeric_utils
Release/unit_string_numeric_utils
As for the dependencies, I agree that it would be nice if the test target
depended on the executables. But what is wrong with make all test (apart
from the fact that it possibly compiles more than you actually need to run
the test)? You could also wrap
I want to only build the tests, because for today's job, rebuilding my unit
tests takes 2 seconds, which I'll do a dozen times as I add functionality.
linking the libraries that would be affected by my changes would take 60
seconds or more.
the add_executable call in a custom function which creates a custom target
(say test_exes) and makes it depend on all the executables:
function(add_test_executable name)
if(NOT TARGET ${name})
add_custom_target(test_exes)
endif()
add_executable(${name} ${ARGN})
add_test(${name} ${EXECUTABLE_OUTPUT_PATH}/${name})
add_dependencies(test_exes ${name})
endfunction()
This works well for me, brilliant!except I added the add_test() line
(above)
Then you can do make test_exes test.
This does not work for me, as I run it like so:
make -j8 test_exes test (yes I have 8 CPUs)
and that runs the 'test' before / in parallel with test_exes.
I have tried to resolve that with my next email to Marcel...
Paul
___
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 CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On 7 July 2010 23:38, Marcel Loose lo...@astron.nl wrote:
On Wed, 2010-07-07 at 17:05 +0200, Michael Wild wrote:
On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
Hi all,
I have looked and can't find the answer, so I turn to the list.
I have a CMakeLists.txt and a subdirectory called utils, which also
has its
own CMakeLists.txt
In the parent CML.txt, I have something like:
ENABLE_TESTING()
add_subdirectory(utils)
In my utils CML.txt, I have
ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
Simplify this to
ADD_TEST(unit_1 unit_1)
CMake will figure out by itself that unit_1 is a target and invoke the
executable correctly (your code would break for multi-configuration IDE
generators).
As for the dependencies, I agree that it would be nice if the test
target depended on the executables. But what is wrong with make all
test (apart from the fact that it possibly compiles more than you
actually need to run the test)? You could also wrap the add_executable
call in a custom function which creates a custom target (say test_exes)
and makes it depend on all the executables:
function(add_test_executable name)
if(NOT TARGET ${name})
add_custom_target(test_exes)
endif()
add_executable(${name} ${ARGN})
add_dependencies(test_exes ${name})
endfunction()
Then you can do make test_exes test.
HTH
Michael
You can further reduce the number of targets that get (re)build by going
into the directory '${CMAKE_BINARY_DIR}/utils' and invoke 'make' there.
You could also define a 'check' target that will build and run all your
test programs. See http://www.cmake.org/Wiki/CMakeEmulateMakeCheck
Best regards,
Marcel Loose.
Thanks Marcel, I combined the solution in the wiki with what was discussed
in my last email, and I ended up with
set (CMAKE_TEST_COMMAND ctest)
function (add_unit_test name)
if(NOT TARGET ${name})
add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
endif()
add_executable(${name} ${ARGN})
# or ADD_EXECUTABLE(${name} ${ARGN} EXCLUDE_FROM_ALL)
#if you want it to be skipped when building 'all'
add_test(${name} ${EXECUTABLE_OUTPUT_PATH}/${name})
add_dependencies(check ${name})
endfunction()
however, I have discovered (with message()) that ${CMAKE_TEST_COMMAND} is
*empty* - its something I had to set(), which is not mentioned in the wiki
page you mentioned. It IS kind-of-mentioned in Cmake Scripting of CTest
but not explicitly enough to catch the eye.
I've edited the wiki page, please check that my edits make sense.
Thanks
Paul
___
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 CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On 8 July 2010 12:56, Michael Wild them...@gmail.com wrote:
On 8. Jul, 2010, at 4:40 , Paul Harris wrote:
On 7 July 2010 23:05, Michael Wild them...@gmail.com wrote:
On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
Hi all,
I have looked and can't find the answer, so I turn to the list.
I have a CMakeLists.txt and a subdirectory called utils, which also has
its
own CMakeLists.txt
In the parent CML.txt, I have something like:
ENABLE_TESTING()
add_subdirectory(utils)
In my utils CML.txt, I have
ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
Simplify this to
ADD_TEST(unit_1 unit_1)
CMake will figure out by itself that unit_1 is a target and invoke the
executable correctly (your code would break for multi-configuration IDE
generators).
This does not work for me. If I do not have the EXECUTABLE_OUTPUT_PATH
in
add_test, I get a message like this when i run make test (shortened for
brevity):
1/ 1 Testing unit_string_numeric_utils Could not find executable
unit_string_numeric_utils
Looked in the following places:
unit_string_numeric_utils
unit_string_numeric_utils
Release/unit_string_numeric_utils
Release/unit_string_numeric_utils
Mmmh, works fine for me:
-8-
cmake_minimum_required(VERSION 2.8)
project(tmp)
enable_testing()
add_executable(unit1 unit1.cpp)
add_test(unit1 unit1)
-8-
Where unit1.cpp is just a simple hello-world program. Running it:
snip
My project is a lot bigger than a hello-world program. It has
subdirectories for a start, and I do things like
SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL Single
output directory for building all executables.)
I'm not sure at which point things stop working, do you want me to try and
build a test-case?
___
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 CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi, my 2c...
2008/11/10 Andreas Pakulat [EMAIL PROTECTED]
On 10.11.08 12:01:13, Fernando Cacciola wrote:
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
There are projects that have headers that are usable without linking
against any library. There are also projects installing their headers into
a common place, that have multiple libraries. In that latter case you'd
have include_directories() point to the common place for the headers, but
obviously you can't know which of the libraries needs to be linked in.
Boost is a good example (albeit it doesn't use cmake to build itself).
they have just added cmake support, i think it was just added to the trunk
There are various libraries shipped with it, they all install their headers
into includedir/boost/libraryname/ and the libs are of course directly
in libdir. And its common practice to have only includedir/boost in the
include-directories.
i would disagree, its common practice to have only includedir in the
include-directories, and then you
#include boost/shared_ptr.hpp
For the case of a single library with a few headers, for which a UseXXX
file is provided the requirement really doesn't make much sense (IMHO) -
unless you can use some of the headers without linking.
(snipped from above)
On 10.11.08 12:01:13, Fernando Cacciola wrote:
Well, I'm questioning this recommended practice because it's half baked:
It makes sense to allow users to control which targets are linked
against CGAL, but NOT if OTOH they cannot control which targets are
given the CGAL include directories, definitions and flags.
That is, IMO, target_link_libraries makes little sense in the absence of
target_include_directories, target_add_definitions and target_*_FLAGS.
What it's so special about linking that only that command can be made
target specific???
I can specify which headers I want to include by writing #includes in my
.cpp file.
But the ONLY place I can specify which libraries I want to include is within
CMake config files. Thus, you only need target_link_libraries and not
target_add_directories.
As for target_add_definitions, you don't add definitions to a target, you
add them to cpp files you are compiling. I think you can define them for
certain files if you have the add_definition in a subdirectory
CMakeLists.txt, but I'm not sure how else you can limit its 'scope'.
Paul
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.3 RC 1
2.6.3-RC-1 is good, the problems I was having with boost (in linux) seem to
have been resolved. I'll check it under windows sometime later.
Question, is there a reason why there is no FindMySQL.cmake included yet?
I have found 2 options, one that can be grabbed from:
http://www.wzdftpd.net/trac/browser/trunk/cmake/FindMySQL.cmake
and a more complicated (and probably complete - it also detects mysql's
taocrypt and yassl) one from the MyODBC source:
http://dev.mysql.com/downloads/connector/odbc/5.1.html#source
see in the cmake directory, there is FindMySQL.cmake and a FindODBC.cmake
file
Note that one other difference is that wzdftpd exposes ${MYSQL_LIBRARIES}
while MySQL-ODBC exposes ${MYSQL_CLIENT_LIBS}
cheers
Paul
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Add external static libraries / ar-archives to a build.
snip
cmake -DBLAS=/path/to/lib/libgoto.a PATH_TO_SOURCE
If I link the lib manually I enter
gcc -o output myfile.c /path/to/lib/libgoto.a
FIND_PACKAGE(BLAS REQUIRED)
ADD_EXECUTABLE(output myfile.c)
TARGET_LINK_LIBRARIES(output ${BLAS_LIBRARIES})
snip
In my opinion the best way is to pass the right file as parameter. The
cause is that the choose of the blas implementation is very important to
solve the problems as fast as possible and so I want an easy way to switch
which blas is used.
Either run it via ccmake and changed whatever option is wrong.
reading the code of FindBLAS.cmake there is apparently a subtle
mechanism which rely on the setting of BLA_VENDOR, change this value
until you are happy with cmake system inspection (neither did I wrote
this module, nor did I ever used it...)
I am in a vaguely similar position, and I can understand the desire to
specify the library on the command line (so that you can configure via a
selection of scripts that call cmake), rather than having to manually edit
the properties in ccmake.
Maybe instead, is it possible to set the value of BLAS_LIBRARIES via the
command line? You would probably also want to set BLAS_INCLUDES too in case
you have different headers as well.
At the end of the day, FIND_PACKAGE()'s goal is to set the values of
numerous standard variables (eg BLAS_LIBRARIES)... so if you can do a
better job than cmake's automatic package finding tool, then it might be
easier to just specify the required variables yourself and remove the
FIND_PACKAGE call entirely.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] qt4_create_translation and add_dependencies
Hi,
I am trying to get cmake to execute the translations command without
success...
Originally I just had an install(FILES etc) command (see below) but make
would complain:
make ...
build build build...
Install the project...
-- Install configuration: Debug
CMake Error at cmake_install.cmake:36 (FILE):
file INSTALL cannot find file
/builddir/app_fr.qm to
install.
So I tried to add in dependencies to force the command to execute:
I have a root CMakeLists.txt:
-
set (FILES_TO_TRANSLATE )
add_custom_target (translations_target)
add_subdirectory(app_library)
add_subdirectory(app_executable)
file (GLOB TRANSLATIONS_FILES translations/*.ts)
qt4_create_translation(QM_FILES ${FILES_TO_TRANSLATE} ${TRANSLATIONS_FILES})
add_dependencies(translations_target ${QM_FILES})
install(FILES ${QM_FILES} DESTINATION ${CMAKE_INSTALL_PREFIX}/translations)
-
and in app_library/CMakeLists.txt
-
file (GLOB CPPFILES *.cpp)
set (FILES_TO_TRANSLATE ${FILES_TO_TRANSLATE} ${CPPFILES} PARENT_SCOPE)
--
and in app_executable/CMakeLists.txt
add_executable(myapp main.cpp)
add_dependencies(myapp translations_target)
--
The FILES_TO_TRANSLATE has the right files once it gets to the
qt4_create_translation() command.
It seems that the lrelease command is never executed, the .qm file is never
generated and thus there is no .qm file to install.
any ideas on how I can figure this out?
thanks,
Paul
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] adding to variables within subdirectories
Hi,
In the root CMakeLists.txt, I have a variable - a list of files...
set( TRANSFILES ) ? how do i create an empty list ?
then i add a subdirectory
add_subdirectory(whatever)
and in whatever/CMakeLists.txt, i want to add some files...
file (GLOB CPPFILES *.cpp)
set (TRANSFILES ${TRANSFILES} ${CPPFILES})
and now, back in the root CMakeLists.txt, I want to do something on that
list of files...
qt4_create_translation(QM_FILES ${TRANSFILES} translation/app_fr.tr)
But, I find that whatever I do to the variable in the subdirectory is not
seen in the root dir... How should I do this ?
thanks,
Paul
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
