Why Incremental build? The first and foremost reason is to save time. Incremental build systems provide you with the ability to avoid recompiling the entire source file and link all object codes each time a procedure changes. It allows you, the programmer, to compile and link in just the procedure containing the change, hence the name "Incremental Build". The Incremental Build System (IBS) discussed in this article comes as an integrated feature of Jasik Design's The Debugger (TD), and the version I'm using is Universal version 2.5.4 (11/18/92). The compiler discussed is the Apple's Macintosh Programmers Workshop (MPW), and the version I'm using is 3.3a14. Unfortunately, MPW's compiler does not support partial compilations, so the only time saver is the linking of your application.
Before I go into depth about how to use these two tools together, the reader should understand how to set up an IBS project in the MPW environment. Setting up an IBS project is required whether you're using IBS in the MPW or the OM environment. Since OM is primarily an object-oriented environment and FrameWorks is an object-oriented development publication, I will narrow my discussion to MacApp applications. For MacApp applications to take advantage of the IBS feature, MABuild must create .map and .sym files. This can be done by adding the -Sym and -LinkMap options to your MABuildDefaults symbol.
Before editing anything in the source, the programmer will have to create an IBS project. This can be accomplished by selecting the "Create Project…" menu item in the IBS menu. When this menu item is chosen, a dialog will appear explaining that an IBS project is defined by an application or tool you are concerned with, and that the .map and .sym files must also reside in the same folder. Click on the "OK" button to acknowledge this dialog, then a Standard GetFile dialog is displayed for you to locate the application. Now navigate to one of the "." folders (ie. .Debug Sym) which contains the application and then click on the "Create" button to select it. IBS will then respond with another information dialog indicating that a "ProjInfo" folder will be created within your "." folder to hold miscellaneous IBS project files. When you acknowledge this, an other dialog comes up asking you to choose the FIRST option that applies to the IBS project that you're creating. In our case it will always be option #1 that reads "is a MacApp based". Select option #1 and then click the "OK" button. At this point a new xxx_IBS.proj file is created in the "." folder where xxx is the name of your application. There you have it. You have created an IBS project for your MacApp application and are now ready to use IBS with your incremental changes.
To verify that you have done it right, select the IBS menu, and you should see your application with the appropriate path listed as one of the menu items at the bottom of the menu. Each time you create a new IBS project, the new project and its path will be appended to the bottom of the IBS menu. The current active IBS project will have a bullet (•) on the left side of its name. Having the correct IBS project active is very important, because if you have the wrong application active, you will not be able to jump to the shell from within TD while you're debugging you rapplication.
Now comes the point I mentioned at the beginning of the article, about having to learn new habits in editing your source. My normal habit when I'm editing my source is to make some small change and than hit Command-S to save my changes; this will be disastrous when using IBS if you have not done an "Add Hint". Before you save any part of your code, highlight the name of the procedure or procedures (including the class name ie. TMyClass::MyProcedure). Wth the name selected go to the IBS menu and select the "Add Hint" menu item. When you select the "Add Hint" menu item, it tells IBS that the procedure highlighted is the one to be edited. It will make a copy of your source file containing the procedure and name it "xxx.cp_old" where xxx is the name of your source file. Now you can perform the change you wanted.
If you forgot to do the "Add Hint" step and if your editing habits are similar to mine, you will have to do a regular MABuild, by going back to TD, killing the application and then doing an MABuild from MPW. This is why I say that your normal routine will have to change, unless your normal routine does not include saving your work every now and then. With unexpected crashes hovering around corners, especially in a development environment, I don't even notice hitting the Command-S combination anymore.
After you are satisfied that all required changes are done, go to the IBS menu and select the "PatchBuild" menu item. This will tell IBS to go ahead and recompile your changes, and then apply the appropriate patches to your object code and send you right back to TD. In TD's "Notes" window you will see a line with your application name and the statement "PLI sym patches installed". This statement indicates that all your changes are in effect and you can continue your debugging.
You may find this all too cumbersome to be useful, but think about the 5 to 10 minutes that a large MacApp application takes to Link. All this time spent just to correct a simple spelling mistake in a variable name. Fortunately, this cumbersome procedure does not have to be endured, because ACI came to our assistance with the creation of ObjectMaster.
To activate the IBS feature, all you have to do is to select the "Incremental Build" menu item from the IBS sub menu in OM. After you "Exited" TD using the "Side Door to Shell", each time a procedure is changed from the Browser window the appropriate IBS "Add Hint" command will be done automatically. Note that only changes from within the Browser window will be tracked automatically by OM for IBS, any changes from within the File window will have no similar effect.
When you're ready to implement your changes, all you have to do is to select the "Patch Build" menu item from the IBS sub menu in OM. Unfortunately, there are no indications within OM that a Patch Build is in progress, so you will not know that something is happening. You will have to either keep the MPW Worksheet visible or switch to MPW to monitor the Patch Build process. As in the MPW environment, when the Patch Build process is completed it will bring you back to TD for debugging. One more additional time saver as compared to MPW is that you can "Kill" your executed application from OM rather than jumping back to TD and terminating the application. This is done by the appropriately called menu item "Kill Problem Program" in the IBS sub menu.
.gif)
.jpg)
