How a missing include file taught me something about bmake

While working on building an installer I ran into a problem with a compilation error about a missing include file.  While trying to fix that problem I learned several things, one of them was something I would have never guessed about bmake.

Part of the code I was trying to build included afxcontrolbars.h, which is in one of the standard include locations in Visual Studio 2008.  However when I tried to compile, I got an error that it could not find the include file.  To check if Visual Studio was set up correctly I created a template MFC application in Visual Studio and was able to compile with the file included without a problem.   Next I tried manually adding the include path to the command line using the -I option.  That ended up with a number of compile errors.  I inspected the files with the errors and it looked like it was an issue with several macros that should have been defined in sal.h but were not getting properly defined.  I included sal.h and still was not able to get a clean compile.  At that point I realized that something more than just a missing include directory was the problem.

I wondered if some files were getting included from alternate directories that were not compatible since I had forced the include path of the missing header file on the command line.  I turned on the -showIncludes option to see where the files were getting pulled in from.  That was very helpful because it showed that none of my include files were being pulled from the Visual Studio 2008 folders; instead they were all in the Visual Studio 2005 folders.  It was compiling with wrong tool set even though BUILD_USING_VS2008 was set in the bmake file.

I looked into what tool set was getting selected with a combination of defining DEBUG_POLICY and %error messages at strategic locations in different bmake files.  What was happening was that the VS 2008 tool set was being setup, but then being overridden later by the VS 2005 tool set.    I didn't understand why this would happen so I started adding in conditional checks for which tool set was being used in my bmake file and narrowed it down to a line like this:

$(Delivery)X.dll :
    bmake $(PathToX)X.mke

If I removed that line the VS 2005 tool set never got setup and I was able to successfully build using the VS 2008 tool set.  That didn't make much sense to me.  I assumed that bmake command would fork off another process with its own set of variables and would have no effect on the settings of the bmake file that called it.  It turns out that I was wrong.  Even if  a bmake $(PathToX)X.mke instead of %include$(PathToX)X.mke can still affect the variables set in the calling make file.  I would have not realized that if I had not seen it happen.