Anyone knows c++ code coverage tool usable under the following conditions:
Target platform is PowerPC CPU inside Nintendo WII dev.kit, that runs custom embedded OS. The only way to exchange data with the PC is to use custom proprietary API (sorry for my NDA).
Compiler is not Microsoft, not GCC, not even command line. Namely it's Metrowerks IDE (running on Windows, of course).
Thanks in advance!
Do you know about BullseyeCoverage. It is a commercial tool, which supports really big number of platforms and compilers. If you don't see you compiler you can write them an inquiry. I did not find the Metrowerks Compiler in the list.
Hope that helps,
Ovanes
See Cpp Test Coverage. This tool can be configured to collect data in embedded systems; you have to figure out how to export an array of bits from inside that system to an external file system, and if you can do that, it can show you precise test coverage.
Does the Metrowerks compiler have special syntax that is not ANSI standard?
My shop has been using a customized version of Covtool. Perhaps that could be ported to your environment.
I have used Cantata. It works with Metroworks. It instruments your code so your application will no run at full speed. You just need rewrite the IO functions so output happens using the custom proprietary API.
Related
My task is to create a C++ SDK - in the form of a dynamic library(s), most likely.
It is supposed to be used on different platforms - Windows (32/64 bit), Linux (32/64 bit), Mac OS, Android and iOS. I don't have much experience with multi-platform project setup and I'm trying to decide what methods and tools to use for easiest development and deployment.
Side note: I will also have to prepare automatic builds (jobs) on Bamboo CI server, in order to run compilation and tests for each required target.
My main dilemmas are:
Project setup. Should I prepare different project schemas for use on different platforms (like .sln on Windows and makefiles on Linux), or maybe try using a tool like CMake? Is it even possible to prepare a CMake project that will suit all these target platforms?
Compilation toolchain. Should I use "native" C++ compilers for every platform (like MSVC on Windows and GCC on Linux), or maybe a single toolchain like Clang + LLVM? Would Clang + LLVM (and some linker obviously) be even able to build distributable binaries for all these platforms I need?
Development Environment. Which OS/IDE would be best for working on that kind of project? I prefer working on Windows and my usual IDE is Visual Studio - would it be viable in this case, or maybe something else would be more appropriate?
I know that my problem is very complex and there is no straight answer for any of these points, but every advice and even partial answer will be much appreciated :)
As you say, there is no one-size-fits all solution, so I will make some general suggestions. Feel free to pick-and-choose as you feel is most beneficial.
If you plan to do your building on the host OS, cmake sounds like exactly the tool for you. It self-describes as a "build system generator", where the steps to build on a specific host OS are abstracted away, meaning the same setup "should" work for any system cmake supports.
If you're thinking of cross-compiling, you're in for some hurt with the iOS and MacOS goals. As far as I know, and I have put some effort into trying, Apple does not release compilers for their systems that do not run on their systems -> You will have to compile for iOS and MacOS from a MacOS computer. If you can prove me wrong on this point, I would be glad to hear it :)
Depending on your licensing requirements, if you really want an overkill solution you could look into Qt* and qmake. I have had excellent luck with their multiarchitecture solutions, and Qt supports all of the systems you listed in your original question. I find Qt + qmake far easier to deal with than cmake.
* Yes, Qt does non-GUI work quite well too!
I touched on this in the second point of 1., but my general suggestion would be to use native toolchains. Excluding MacOS, it's easy to set up Virtual Machines, build server, etc. to build native code, and my experience with cross-compilers is they always add another layer of heartache, even worse than having to remote-access a separate builder computer.
Provided you avoid system-dependent headers, libraries, or extensions, it shouldn't matter what system you use. Things like <windows.h> and <linux/*.h> are obvious, but the best way cross-platform compatibility can be verified is by testing the foreign systems as often as possible.
Agnostic of compiler used, I would suggest turning on all the warnings. They are usually important, and may indicate a place where the compiler was able to band-aid over a problem but trying to compile for another system will blow up. If you're working on a team, it might be a good idea to set warnings to result in build errors to make sure the rest of the team is as rigorous as you are.
I don't know about LLVM or MSVC, but GCC will give you some hints as to platfom-specific extensions if you give it the -pedantic and -ansi flags. As explaind here, those flags tell GCC to warn for any GNU-specific extensions.
You are very likely going to need multiple tool-chains (you mention C++ and it has no ABI so to be usable on Windows you are more or less required to build with CL). It follows that you will not be able to use a single vendor-specific project setup. As the project grows maintaining multiple versions of project files becomes quickly untenable so your choice of build system is critical. Have a look at Shake and compare to alternatives with a similar feature-set. The choice of IDE is of less importance - many programmers prefer their favorite editor (Emacs or Vim) and may need to do work on any of the supported platforms.
I am required to write a C++ application to run on an embedded Linux setup (DMP Vortex86DX processor). The vendor provides a minimal linux installation image that can be installed to the board and contains appropriate hardware drivers. My question is motivated by the answer to my previous question about writing Linux software on a particular kernel to run on a different kernel . I don't really know where to start when it comes to writing the software with regards to ensuring compatibility.
My instinctive approach would be to install the same versions of g++ on the embedded device and on my desktop development machine, write the application on the dev maching, copy to the board and compile it there. This seems madness though and I find it hard to believe that this is how embedded software is developed. With regards to the answer to my previous question, is there a way I can simply build on my desktop but use the version of glibc that exists on the embedded device - if so how can enforce linkage to a specific version? Or is it possible to build everything statically so that the application doesn't link to anything dynamically (I doubt this is possible).
I am a total novice to embedded development, and foresee months of frustration unless I can get hold of some good advice or resources. Any pointers or suggestion of where to start will be very gratefully received no matter how simple or trivial they seem - I really am starting at the very bottom with regards to embedded stuff.
OK, given the fact that the Vortex86SX/DX/MX claims to be x86 compatible, a small set of compiler switches should enable you to compile code for your target machine: -m32 to ensure 32bit code, and no -march switch targeting a specific CPU.
Then you'll need to link your code. As long as you don't use anything fancy, but simple established glibc functions, I'd expect the ABI to be the same on your development machine and the embedded system. In other words, you compile against your host libraries, copy the binary to the embedded system, and it should simply run using the libraries available there.
If X-Linux were to use some other libc, like uclibc or similar, then you'd need a cross compiler on your host. I have little experience with Ubuntu in that regard, but I know that the sys-devel/crossdev package for Gentoo linux makes generation of cross-compilers very easy. This can be both for different architectures (not needed in your case) and different libraries (like e.g. uclibc).
I'd say simply give copying the binaries a try, and report back if you encounter any problems there.
What code coverage tools have you used with Symbian C++ and Maemo? What are the pros and cons of the tool you are using?
On Symbian I've used BullseyeCoverage and Testwell CTC++. Cannot really describe the pros/cons of them in detail. Both got the job done, eventually. Both needed some effort with setup and integration with an automated test suite. Both contained bugs that e.g. crashed the downstream compiler with slightly broken instrumented source code.
On Maemo, since the toolchain is GCC based, I'd guess gcov would be a good starting point. Though I haven't been working on Maemo much yet and haven't done any coverage measurement there.
See SD C++ Test Coverage for a tool that has extremely low overhead and works very well in embedded environments.
I have used Bullseye Coverage on Symbian and it is very good. The only problem is that it only runs on emulator and not hardware. Therefore you would not be able to get coverage metrics from a device or devboard. If your app runs on both hardware and emulator, this won't be a big deal (apart from the standard differences between running on emulator vs hardware). Also, as there are plans to replace the emulator with a proper hardware simulator, perhaps bullseye wouldn't be the best choice.
gcov can be used (and is used) in maemo platform and tool called lcov can then be used to generate "pretty" reports.
However, in order use gcov in maemo sdk, you need to disable compiler cache during the build time when you are creating binaries for coverage execution..
Currently I`m using Visual Studio for writing code in C++. But it seems so weighty that I decided to switch for another one, preferably free, not so strict to system resources (I mean memory, of course) as VS to learn libraries, such as Boost and Qt. What compiler do you suggest?
I'd suggest using Visual Studio's compiler from the command-line. You get the same high-quality compiler, without the resource-hogging IDE.
Although the IDE is pretty good too, and probably worth the resources it uses.
Code::blocks is exactly what you are after. You can can download it here: http://www.codeblocks.org/downloads/5
Choose the version with the mingw compiler bundled with it (Windows port of GCC). You can switch between that and the VC++ compiler as and when you like.
Code::Blocks has all the stuff you want, debugger integration, code completion, class browser, todo list etc. etc. It even import visual C++ projects.
Don't use Dev C++ which has already been recommended. It's very very old and outdated.
If you want to learn unix tools download and install cygwin It's a good set of tools but a full install takes up 5 or 6 gigs because so much is included.
There is always Digital Mars. Also, you can freely download Microsoft WDK
which comes with their C/C++ compiler and command-line build system.
You will be hard-pressed to find an IDE as capable as MS VS. It is incredibly feature-rich.
However, if you just want command line compiling and linking it can do that too.
GCC is also an option.
Please note that you do not need another compiler or IDE to use boost libraries. I wouldn't replace Visual Studio with any other IDE/compiler, at least not on Windows. Installing Cygwin or SUA (better than Cygwin, closer to the Windows Kernel) will only be a pain just for what you are trying to reach.
Try to minimize the memory usage by disabling unnecessary things, keep the amount of open source files small, use an alternative to document explorer to find help (your browser on msdn will do). Besides that, I wouldn't call a few ten megabytes of memory a high usage. As long as it doesn't slow your system down there is not a real issue.
A better idea would be to upgrade your computer rather than to replace something powerful with something that you don't know.
Seriously there is no real alternative to Ms's compiler on Windows. All the others are OK if you can't spring for Visual Studio or if you are just doing hobbyist work. Cygwin can be a pain to deal with.
If you don't want the IDE as someone else suggested just use the command-line compiler.
I've found VS to be quite good for doing Boost + Qt work. Especially if you have the Qt + VS integration tool. You get a GUI designer and respectable Qt project management tools.
If you are looking for a compiler that uses fewer system resources than the MS ones, you'll probably find that most modern compilers that are able to compile a good part of or almost everything in Boost will be quite heavy on system resources, both processor usage and memory consumption. To a certain extent that's just par for the course when it comes to C++.
That said, I do like to have a second compiler around if I'm writing portable code as it's a lot easier to iron out portability issues when you can ensure that the code compiles in different environments. If you want to do all that on Windows, may Cygwin is worth a look. However it does seem that the GCC you get with Cygwin is not exactly what you'd call up to date.
The aforementioned Digital Mars compilers are well worth a look, Walter Bright (the guy behind them) has been writing C++ compilers for a long time and they're pretty good. I have used them off and on since the early nineties and I've always been happy with them. Not to mention that they always seemed noticeably faster than the Microsoft offerings, but I haven't got any recent measurements to back that up.
At the end of the day, most third-party tool vendors on Windows tend to target the MS environment so if you're writing C++ code professionally and need/want tools like leak detectors, you pretty much need to be able to build with the MS compilers, even if they aren't your main development environment.
I sugget , Netbeans.org
NetBeans IDE , download the Cygwin , follow one tutorial from http://www.netbeans.org for C++ confuguration at Netbeans IDE , just 2 steps.. and u are ok
autocomplete (faster than VS')
classes
and all... you want xD
It needs to mention about DevCpp. It is a simple UI wrap for gcc compiler (oh my, it is sounds like a tautology). It provides lightweight IDE but not so stable (so, its IntelliSense is somewhat buggy).
If you use Qt why not use their IDE, QtCreator, there is compiler, debugger and GUI designer. All comes in one nice package and works on Windows, Mac and Linux.
In my opinion it's better than Code::Blocks (also based on MinGW/GCC).
I have a very large code base that contains extensive unit tests (using CppUnit). I need to work out what percentage of the code is exercised by these tests, and (ideally) generate some sort of report that tells me on a per-library or per-file basis, how much of the code was exercised.
Here's the kicker: this has to run completely unnatended (eventually inside a continuous integration build), and has to be cross platform (well, WIN32 and *nix at least).
Can anyone suggest a tool, or set of tools that can help me do this? I can't change away from CppUnit (nor would I want to - it kicks ass), but otherwise I'm eager to hear any recommendations you might have.
Cheers,
Which tool should I use?
This article describes another developers frustrations searching for C++ code coverage tools. The author's final solution was Bullseye Coverage.
Bullseye Coverage features:
Cross Platform Support (win32, unix, and embedded), (supports linux gcc compilers and MSVC6)
Easy to use (up and running in a few hours).
Provides "best" metrics: Function Coverage and Condition/Decision Coverage.
Uses source code instrumentation.
As for hooking into your continuous integration, it depends on which CI solution you use, but you can likely hook the instrumentation / coverage measurement steps into the make file you use for automated testing.
Testing Linux vs Windows?
So long as all your tests run correctly in both environments, you should be fine measuring coverage on one or the other. (Though Bullseye appears to support both platforms). But why aren't you doing continuous integration builds in both environments?? If you deliver to clients in both environments then you need to be testing in both.
For that reason, it sounds like you might need to have two continuous build servers set up, one for a linux build and one for a windows build. Perhaps this can be easily accomplished with some virtualization software like vmware or virtualbox. You may not need to run code coverage metrics on both OSs, but you should definitely be running your unit tests on both.
If you can use GNU GCC as your complier, then the gcov tool works well. It's very easy to fully automate the whole process.
If you are using the GCC toolchain, gcov is going to get you source, functional, and branch coverage statistics. gcov works fine for MinGW and Cygwin. This will allow you to get coverage statistics as well as emitting instrumented source code that allows you to visualize unexecuted code.
However, if you really want to hit it out of the park with pretty reports, using gcov in conjunction with lcov is the way to go. lcov will give you bar reports scoped to files and directories, functional coverage statistics, and color coded source file browsing to show coverage (green means executed, red means not...).
lcov is easy on Linux, but may require some perl hacking on Cygwin. I personally have had some problems executing the scripts (lcov is implemented in perl) on Windows. I've gotten a hacked up version to work, but be forewarned.
Another approach is doing the gcov emit on windows, and doing the lcov post processing on Linux, where it will surely work out of the box.
Check out our SD C++ Test Coverage tool. It can be obtained for GCC, and for MSVC6.
It has low overhead probe data collection, a nice display of coverage data overlayed on your code, and complete report generation with rollups on coverage across the method/class/file/directory levels.
EDIT: Aug 2015: Now supports GCC5 and various MS dialects through Visual Studio 2015. To use these tools under Linux, you need Wine, but there the tools provide Linux-native sh scripting and a Linux/Java based UI, so the tool feels like a native Linux tool there.
I guess I should have specified the compiler - we're using gcc for Linux, and MSVC 6 (yeah I know, it's old, but it works (mostly) for us) for WIn32.
For that reasons, gcov won't work for our Win32 builds, and Bullseye won't work for our Linux builds.
Then again maybe I only need coverage in one OS...