Down the open source rabbit hole again... here is a running record of what it took to get myself the ability to build wxWidgets projects.
Mistake #1: Using the 2010 version of Virtual C++. Nearly all of the documentation on the wxWiki, and all of the source and sample code and projects that were installed for 2.9.1, and the Opal Kelly projects all expect that I am using VCpp 2008. Sadly, it's just too late for me to back 2010 out considering all that I've built with it so far for the Opal Kelly.
The alpha article on wxWiki that has saved my ass dozens of times so far:
http://wiki.wxwidgets.org/Microsoft_Visual_C%2B%2B_Guide#Visual_Studio_C.2B.2B_2010.
From this guide, I learned the supposedly obvious fact that once wxWidgets is downloaded, it has to be built. Duh. Doing this makes the wxWidgets libraries which are then linked into applications at compile time, which I suppose would be more efficient than just recompiling wxWidgets each time.
From this guide I followed the trail to where to download a version of the libraries project that somebody made in order to fix the Express 2010 problems which made it impossible to compile the wxWidgets library projects which were distributed with 2.9.1: "Microsoft.CppCommon.targets Invalid command line switch for "cmd.exe". The path is not of a legal form."
http://forums.wxwidgets.org/viewtopic.php?t=27630
The fixed library projects compiled perfectly. So, next I tried compiling one of the samples. The samples all seemed really fractional, mostly just demonstrating single features each. Since the guide suggests basing my own projects on "internat" I started with that. It failed to find the rather central setup.h file. More googling revealed that this turns out to be a failing of this particular sample and has been encoutered by many people. The solution is to add the path to setup.h in the include files directories under preprocessor properties, according to the following dense but helpful looking other guide page on the wiki:
http://wiki.wxwidgets.org/Compiling_using_MS_VC%2B%2B
After that, I begin having problems finding header files and then finding libraries. What I discovered is that all the library files that I'd made were under mswud instead of mswu. I figured out that what had happened was that when I compiled the libraries, I must have only compiled the debug configuration. So, for a while I relied on a workaround of compiling samples in debug configuration. I began to have success in compiling samples and demos, including the clone of the "minesweeper" game.
After that, I took the next step of moving a sample to my own directory structure to compile it there. To perform this step, I used the technique of opening up a .vcproj file from the original samples director in wordpad (it turns out it's just an XML file), and changing all of the relative paths in the file to hard-coded paths to the wxWidgets install directory. This is where having that environment variable set was important, although I often just got lazy and hard-coded the path directly in the .vcproj file rather than use the environment variable.
After that, I got started trying to compile the Opal Kelly counters project. Since I now distrust the project files distrubted by OK, I tried building a new project from scratch using a new empty project. I opened up one of the sample project files in wordpad and tried to transfer as much of the wxWidgets environment over as I could. However, the information in the project file is widely distributed and I missed a bunch of stuff, like the preprocessor directives for the resource files. I was clued into this by this page which had dummy-followable steps on to how to build up the wxWidgets environment in a fresh project file. I loved this page until I noticed that it doesn't make a distinction between Debug and Release configurations, and seems in fact to be configuring a Debug compile:
http://rhyous.com/2009/12/16/how-to-compile-a-wxwidgets-application-in-visual-studio-2008/
The following section of the alpha Guide is more dense, and seems to miss the setting up of resources, but at least provides some background on why to use or not use various preprocessor flags and libraries:
http://wiki.wxwidgets.org/Microsoft_Visual_C%2B%2B_Guide#Creating_a_New_Project_by_Hand
Anyhow, as Counters began to compile, I ran into a problem with one line in the program where it attempted to pass a string argument using a member of an wxWidgets string container. It appears as though this is a compatibility issue between wxWidgets 2.9.1 and 2.8.x, at least according to the spirited debate in the comments to this bug report:
http://trac.wxwidgets.org/ticket/9507
I fixed it by adding a direct cast, although I had to do it slightly differently than described in the trouble ticket, because the destination type was different in the OK code.
So, suddenly I had a clean compile, except when I took it to the target system it complained about a missing debug DLL. So in the end, I had to just build the Release versions of all the libraries, fill in everything in the project setup for a release configuration, and boom it works.
