Getting PLL to build on my new machine - CppUnit Step

This is the second post in a series logging the steps I have to go through to get PLL to compile on my new machine. 

CppUnit  update Step

http://www.freedesktop.org/wiki/Software/cppunit

This is now hosted in a Git repo, so I need a Git client... TortoiseGit looks like the best player as usual... do I really want another shell integrated tool?  Can I just use it and uninstall it?  Why can't the maintainers of CPPUnit just have a package for download?

http://code.google.com/p/tortoisegit/downloads/list

Oh wait... now I need MsysGit too... oh and its homepage has moved too... what a total armpit!
More installation options that I don't care about.  All I want is the freakin CPPUnit so I can get my freakin project working.

http://msysgit.github.com/

Ok, set up.. lets rock... copy past url into git clone... doing stuff....

"Git did not exit cleanly".   Fatal: I don't handle protocol 'git clone git' 
Take a guess and remove the bits that look like duplication.... success.  Whoot! only 32456 steps to go.

Now just some tweaking to add it to the search path.  VS has changed the way it handles include paths... they are now part of each project property set...

Set the path to the CPPUnit Include directory... minor fiddle and its working... whoot.  (Not built yet... just finding the includes)

First lets play build CPPUnit...

Convert the VS2008 project, check for errors... cross fingers and build the solution. 

Something died.  cmd.exe exited with code 1.  in DLLPlugInTesterTest Project. ????

15 Errors
170 Warnings....

Should I even bother?

Ok the errors are a cascade caused by the first failure.

The warnings however are only of two types.
152 x Warning C4251  ... blah blah needs to have dll-interface to be used by clients of class... etc.
18 x  Warnings MSB8012 about output path missmatches.

Changed the librarian output target for the cppunit project to Debug\cppunit.lib rather than Debug\cppunitd.lib which cleared all the errors and allowed the projec to build correctly and copy the file to the libs directory correctly.

Whoo Hoo!

Now on to cppunit_dll project

Remove the "d" for debug from the linker output target name to get rid of the compiler warnings.
After some fiddling around and remove the \.\ from the Output Directory and the Intermediate Directory (Do I need to do this in all the projects?) I also removed what seemed to be a spurious post build step

"copy "$(TargetDir)$(TargetName).lib" ..\..\lib\$(TargetName).lib"

As there did not seem to be a .lib being built ( its a .dll project?) this step was failing and blocking.

But now when I build the solution again, there is another project looking for the cppunitd_dll.dll in the libs directory?  Are you kidding?

Ok, quicky rename...

Build the solution again...

More errors due to the ".\" in front of the output Directory and Intermediate directory in all the other projects, so I removed them all in one hit.

Still cannot find the cppunitd_dll.lib to copy it.  WTF is it being generated?

Found where the libs are being generated and its got another explicit name reference that needs to be changed (Linker > Advanced) Remove the "d".  There is also a ref to cppunitd.lib in the other includes that is pulling in the from the libs directory that needs to be changed.

Money project has embedded "d" and a reference to cppunitd.lib on the libs path that needs to be fixed.

Ditto for CppUnitTestMain. Remove the "d" on the cppunitd.lib on the libs path.
Ditto for CppUnitTestPlugIn  which has a reference to cppunitd_dll.lib - remove the "d" and remove it from the target output name
Ditto for DllPlugInTesterTest
Ditto HostApp has two references in the libs path that need fixing.
Ditto TestPlugInRunner has two references two.

Go through and systematically check all the lib paths and remove the "d"s.

Change the ClockerPlugin to user a post build step rather than trying to directly write the output file to the libs directory.

Later...

Got  sick of changing all the absolute names and set them to $(TargetPath) instead.

After changing all the names in all the property pages, there are still references to cppunitd_dll.x showing up. I have finally tracked them back to the DLLPlugInTesterTest.vcxproj file.

There is a custom build rule in this file that does not appear in the property pages correctly.
msdn.microsoft.com/en-us/library/ee862524.aspx


This is a reference to what the file is supposed to be for.  The question is why its holding this weird reference that will not die and why I cannot edit it using the normal property pages.

DOH!

The stupid file is included in the project.  Thats where the damn reference has origionated.

Now to get simple_plugin working....
 OK. It has a bad name in the post-build step.  Fixed.

HostApp and CppUnitTestApp both have DLL dependencies that include the "d" on the end. Fix them and they run fine.
TestPlugInRunner also has a referene that needs to be fixed.

Now everything builds correctly and the only failure is the simple_plugin.dll test which is illustrating a bunch of assert failures.

We are done! (A day later...)Now I just have to include the include and lib directories in the relevant PLL projects properties.

At some point I may go back and add the "d" to all the debug builds, but honestly, I would prefer to simply build the release version over the top and replace the files.

Now just for fun, lets build the release version....


Here is another fix for CppUnit on Visual Studio 2010
http://blogs.powersoft.ca/erict/archive/2012/02/21/cppunit-in-vs2010ndashwith-a-sample.aspx

Now to fix all the warnings.

LNK4099: PDB 'vc100.pdb' was not found with ....  Copy the file from the debug object directory to the lib directory.