Nice example, good job. I'm trying mostly the same. I don't understand why you want to run test on target platform. I guess (because tests are platform independent) it is ok to run tests only on host. Or I miss something?
CppUTest supports also memory leaks detection. When you include (#include <CppUTest/MemoryLeakDetectorNewMacros.h> #include <CppUTest/MemoryLeakDetectorMallocMacros.h>) in each compiled file you will get also name of file and line that cause memory leak. But when you build for target you have not to include those files. Can this be implemented in cmake by Configuration/BuildType? >From my point of view the package has to have two configurations/BuildTypes >one is Production second is Test. Production: will build target e.g .so .a ... and it can build in debug or release. Now I'm confused because I have BuildType production but I need debug and release build type within Production BuildType. How Can I do that? Test: Will build test executable. Thanks in advance Stevo From: [email protected] [mailto:[email protected]] On Behalf Of Davis Ford Sent: Saturday, September 15, 2012 8:48 PM To: CMake Mailing List ([email protected]) Subject: [CMake] Newbie questions; dual targeting, unit test support, cross-compilation Hi, I'm still trying to get up to speed on CMake, but I have a couple of questions that may fall into a sort of 'best practices' category, or just generally wondering if someone can point me to a couple examples that may be similar to what I want to accomplish. I'm starting a new project that will be targeting Raspberry Pi http://www.raspberrypi.org/ (essentially Linux/Arm). I'd like to follow a development process that includes unit testing + mocks. I recently read the book http://pragprog.com/book/jgade/test-driven-development-for-embedded-c and I'm interested in following this approach and using the test framework CppUTest http://cpputest.org I want the build to support dual-targeting -- meaning the code / build is designed to run on at least two targets: the dev. machine and the target hardware. This allows me to design and test most of the code independent of the hardware. This is the approach outlined in the book. I'd also like to support cross-compilation so I can build for the target on the dev. machine to avoid longer compilation times on slower Pi hardware. I also want to support running the tests via the build - both on the dev. machine - b/c it is fast, but I also want to support building/running the same tests on the target hardware. It seemed like CMake had some nice features that could make setting this up easier, so I'm trying to build out a skeleton project to see how well it works. I hacked together a starter project for this here: https://github.com/davisford/cmake-cpputest - currently it will build a pseudo LedDriver and I can also build & run the tests. I have yet to add the Arm support for the Pi. I'd appreciate any pointers / suggestions or constructive criticism on what I've currently got - how I could do it better, or links to other projects or sections of projects that would be helpful as input. Thanks in advance! Davis
-- 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
