Engine compilation oddity

#1 Hmmm...you might be running into an issue I just figured out last night. If you compare the pre-processor defintions of the engine project to the engine lib project, you will discover that the engine lib project has the extra definition of MAX_UTIL. A quick search through the C++ source files will reveal that this definition greatly alters the shape (ts) code behavior. When you compile the libs first, eninge second, engine lib thrid, and tools last the obj's that the engine lib links together are the ones compiled by the engine project without the MAX_UTIL define. This is why the your exporters won't work correctly (becuase they expect the behavior defined by MAX_UTIL). The reverse is also true: if you compile the engine lib first then the engine project the obj's will be compiled with MAX_UTIL defined and the tools will work but the engine will have problems. Messy, huh? However, there is a simple (if slightly tedious) fix =) Simply, open the engine lib Project->Settings, make sure the v12 Engine Lib project is selected, and click on the General Tab. You should see the Output directories box with the Intermediate files: filed inside. Simply change that to out.VC6.RELEASE/lib and out.VC6.DEBUG/lib for the respective builds. Now comes the tediuos part =) Since the different parts of the engine are defined to place their obj's in subdirs of the Intermediate files dir, simply changing the Intermediate files dir won't change them. What you have to do is click on each of the engine lib folders (in Project->Settings) that has something in it and add /lib after RELEASE or DEBUG (i.e. out.VC6.RELEASE/lib/collision). Be sure to do this for all of the source folders with files in them for both the RELEASE and DEBUG build. Once this is done, the engine and the engine lib will palce their intermediate files (obj's) in different dirs and they will be compiled correctly. This change will most definitely be included in the first patch =)

#2 Just curious, but are all these little tid bits being added to a FAQ somewhere? I can imagine the horror of trying to find them in the threads later 8)

#3 Wow. Thanks for the information. I think I'm confused now =)

The problem only appears to be with the release build. I can compile the debug version the way I want and do quick testing. I just have to do a full rebuild if I want to use the release version. That's not so bad.

I'll check out those settings, though. That sounds like it's probably the culprit :)

#4 I am seeing the same behavior when using VC to try and incrementally build header file changes. It does not appear that dependant files are getting compiled automatically - which will wreak havoc on the EXE. You wont get any compile errors because VC is just sompiling your changes - not the dependant files.

You can also see this phenomenon if you change the signature of a virtual function. Even though some of the derived classes don't use this virtual method, they still need to be recompiled because their v-table information needs to be regenerated. Because VC is not rebuilding dependant files, you will get a linker error from those derived classes telling you that it cant find the old virtual method.

A "rebuild all" works becuase those dependant files are getting recompiled. If you just change implementation code (in .cc) files, everything generally works fine. It's just when you change class definitions that other classes depend on - that causes the problems.

We have had this problem in the past with VC here at work and the problem can be resolved via some magic project settings, I hope. I am going to try and figure it out this week and will post any information I can find.