Question about practical usage of CppUTest in a dual (or more)-target system
Chris
I recently finished and enjoyed Mr. Grenning's book. I can see how the TDD methodology will help our team (if I can get the old-schoolers aboard) to shorten our integration time, which is always what kills schedules for us.
My questions are about how you guys who use the tool every day really use it. Here's what I'm thinking:
- Build CppUTest with each target's compiler once, then just link against the library. I would update the Makefile's CPPUTEST_xxx_DIR variables to produce separate outputs, so I have (for example) lib/mingw/libcpputest.a and lib/powerpc-eabi/libcpputest.a. My project's Makefile links as appropriate for the target.
- I have to do this on each computer at which I work (we have different workstations for different things), but I don't really like have having binaries under revision control so there's no way around it. It's not very onerous if I version control the modified Makefile anyway.
Is that more or less how people set up the library? Is there a better/official/standard way? I'm pretty new to maintaining projects outside of IDEs and autogenerated Makefiles, so I'm outside my comfort zone and want to make sure I'm off on the right foot.
Thanks very much!
Bas Vodde
Hi Chris,
I don't think you need to change the Makefile, but instead you can call the Makefile and override the values. For example "make CPPUTEST_OBJS_DIR=/tmp/mytarget"
I usually just call the CppUTest Makefile from other Makefiles and override the values that I need to. I know Bryce (who is on this list) does a lot with Makefiles and multiple targets, maybe he can share some of his experiences too :)
Hope this helps?
Bas
Bryce Schober
Chris
Bas, I did try overriding CPPUTEST_LIB_DIR, and the library was correctly built and placed. Later in build/MakefileWorker.mk, however, on line 258 CPPUTEST_LIB is defined to be $(CPPUTEST_HOME)/lib/libCppUTest.a, which causes $(TEST_TARGET) to fail to link. So I changed $(CPPUTEST_LIB) to be equal to $(CPPUTEST_LIB_DIR)/libCppUtest.a and got closer to what I wanted. I'm not sure if there are other consequences of that, or if it's a bug in the makefile or what.
Thanks for the help.
Bas Vodde
Hi Chris,
> No worries, it was a pretty vague question to begin with. I'm beginning to think just testing the target-independent stuff might be the best way to go to get up and running quickly. I have dreams of running automated tests which (for example) loop a DAC back to an ADC, write a pattern and read it back to check. We have those tests now, but it's far from an integrated process and they always seem to get dusty and forgotten about until there's a visible bug (which could have been caught earlier). I should probably back up and start smaller.
Oki kewl :)
> Bas, I did try overriding CPPUTEST_LIB_DIR, and the library was correctly built and placed. Later in build/MakefileWorker.mk, however, on line 258 CPPUTEST_LIB is defined to be $(CPPUTEST_HOME)/lib/libCppUTest.a, which causes $(TEST_TARGET) to fail to link. So I changed $(CPPUTEST_LIB) to be equal to $(CPPUTEST_LIB_DIR)/libCppUtest.a and got closer to what I wanted. I'm not sure if there are other consequences of that, or if it's a bug in the makefile or what.
Yeah. I checked this closer and it doesn't seem to be a bug (James: Could you check this too?). The CPPUTEST_LIB_DIR is the directory for output of whatever the MakefileWorker is creating. This can be the CppUTest library itself, but this could also be something else. The CPPUTEST_LIB is actually used as the place where CppUtest itself can be found (per definition). So, replacing them will probably not work well.
I suggest that as an alternative solution you can also override CPPUTEST_LIB when calling the Makefile and pass the appropriate CppUTest library to it?
Thanks!
Bas
>
> Thanks for the help.