20.8 Cleanup

When you get through working on a program, you want to clean up the directories. The directory with your source code will have some files you don't need.

The *.opt, *.ncb and *.plg files (just to mention some examples) are what one might call 'mystery garbage files.' The Microsoft documentation doesn't seem to talk about the mystery garbage files. They reappear every time you compile the program. Bottom line is this: you can delete the *.opt, *.ncb and *.plg (and certain other garbage files) with impunity at the end of a day's programming. These files are just wasting disk space and will be automatically regenerated the next time you build the program. Do be sure to keep your source code, your *.dsw, and your *.dsp.

In addition, the Debug and/or Release directories in particular are going to have a lot of files in them that you don't need. First of all, they'll have a huge 'precompiled header' file with the *.pch extension, the intermediate *.obj files, and some additional junk files.

One way to clean up is to use the Build | Clean selection (its full name is Build/Clean Solution in Visual Studio.Net). If your configuration is set to Debug, this command will remove all the files in the Debug directory; If your configuration is set to Release, this command will remove all the files in the Release directory. But Build | Clean will not get rid of the various kinds of additional intermediate or support files that Visual Studio will write into your basic source-code directory.

Depending what kind of building, debugging, profiling, and so on you've been up to, there are a variety of these extraneous files that may be present. And you might as well delete the Debug and Release subdirectories once they're empty. Unfortunately, Build | Clean doesn't do all of this for you.

Instead of using the Build | Clean file selection, the author prefers to do a more thorough job of deleting things by using a batch file clean.bat that he keeps in the current project directory. You will find a copy of it in the Pop source-code directory.

If you double-click on this file in Windows Explorer it will run in 'console mode' (formerly known as DOS mode) and get rid of the extra files. Here's the contents of a typical version of the clean.bat file. You won't always have all of these kinds of files present, but depending on what you've been doing, any of them can occur.

REM Delete Garbage Files 
del *.aps 
del *.ilk 
del *.map 
del *.ncb 
del *.opt 
del *.plg 
del *.pbi 
del *.pbo 
del *.pbt 
del *.pdb 
del *.tmp 
del *._xe 

REM Delete hidden archived garbage files, first changing their 
REM attributes. 
attrib -h -a *.gid 
del *.gid 

REM Optional: Delete Visual Studio Solution user options, which can be 
REM useful to keep. 
REM attrib -h -a *.suo 
REM del *.suo 

REM Delete Garbage Directories 
del enc temp folder\*.* 
rmdir enc temp folder 
del DEBUG\*.* 
rmdir DEBUG 
del RELEASE\*.* 
rmdir RELEASE 

REM Optional: delete the executables that the project has written 
REM to root. 
REM del *.exe 

In case you can reuse clean.bat for other projects, note that it's designed for the case where your *.exe files aren't saved in the Debug and the Release subdirectories (but are being saved in the source directory as pop.dsw is set to do).

Somewhat annoyingly, the del DEBUG\*.* and del RELEASE\*.* will pause and ask you in a DOS window if you really want to delete those files. You need to press y and Enter. Windows 98 has a deltree command that lets you do this in one step, but Windows NT doesn't support deltree.

Note that as the clean.bat paths are directory-relative, you need to put a copy of it into each of the new source-code directories that you work in.

The Pop project is set to put its *.exe builds into the same directory as the code. Although clean.bat could remove the executables with the del *.exe line, by default we comment this behavior out with the letters REM. The assumption is that you may want to cut and paste the *.exe to another location before zipping your directory.