Nicolas Besson - Microsoft Windows Embedded CE 6.0 Exam Preparation Kit

■ INCLUDESLists additional directories to search for include files.

■ SOURCESDefines the source files to be used for this particular component.

■ ADEFINESSpecifies parameters for the assembler.

■ CDEFINESSpecifies parameters for the compiler, which can be used as additional DEFINE statements for use in IFDEF statements.

■ LDEFINESSets linker definitions.

■ RDEFINESSpecifies DEFINE statements for the resource compiler.

■ DLLENTRYDefines the entry point for a DLL.

■ DEFFILEDefines the .def file which contains a DLL's exported symbols.

■ EXEENTRYSets the entry point of an executable file.

■ SKIPBUILDMarks the build of the target as successful without an actual build of the target.

■ WINCETARGETFILE0Specifies nonstandard files that should be built before building the current directory.

■ WINCETARGETFILESThis macro definition specifies nonstandard target files that Build.exe should build after Build.exe links all other targets in the current directory.

■ WINCE_OVERRIDE_CFLAGSDefines compiler flags to override default settings.

■ WINCECPUSpecifies that the code requires a certain CPU type and should only be built for that particular CPU.

In addition to the standard directives, Windows Embedded CE Sources files support the direc­tives PRELINK_PASS_CMD and POSTLINK_PASS_CMD. You can use these directives to perform custom actions based on command-line tools or batch files before and after the build process, such as PRELINK_PASS_CMD = pre_action.bat and POSTLINK_PASS_CMD = post_action.bat. This is useful, for example, if you want to copy additional files to the release directory when developing a custom application.

If you look closer at the contents of a subproject folder, you can also find a file named Makefile to provide default preprocessing directives, commands, macros, and other expressions to Nmake.exe. However, in Windows Embedded CE, this Makefile includes only a single line that references %_MAKEENVROOT%\Makefile.def. By default, the environment variable %_MAKEENVROOT% points to the C:\Wince6OO\Public\Common\Oak\Misc folder and the Makefile.def file in this location is the standard Makefile for all CE components, so you should not modify this file. Among other things, the Makefile.def file contains include statements to pull in Sources file, such as !INCLUDE $(MAKEDIR)\sources, which specify the Sources file from the subproject folder. You should edit the Sources file in the subproject folder to adjust the way Nmake.exe builds the target file.

The Windows Embedded CE 6.0 R2 development environment relies on Makefile, Sources, and Dirs files to control how Build.exe and Nmake.exe compile and link source code into functional binary components for the run-time image. You can use Dirs files to define the source code directories included in the build process or Sources files to specify compile and build directives in greater detail. The Makefile, on the other hand, requires no customization. It merely references the default Makefile.def file with general preprocessing directives, commands, macros, and other processing instructions for the build system. You must thoroughly understand the purpose of files and how they control the build process if you want to clone public catalog items or create new components efficiently.

You are certain to encounter build errors during the software-development cycle. In fact, it is not uncommon to use compile errors as a syntax check for source code, although IntelliSense® and other coding aids available in Visual Studio 2005 help to reduce the amount of typos and other syntax errors. Syntax errors are relatively uncomplicated to fix because you can double-click the corresponding error message in the Output window and jump right to the critical line in the source code file. However, compiler errors are only one type of build errors that can occur. Other common build errors are math errors, expression evaluation errors, linker errors, and errors related to run-time image configuration files. In addition to error messages, the build system also generates status messages and warnings to help you analyze and diagnose build issues. The amount of information generated during the build process can be overwhelming. You need to know the different types and general format of build messages if you want to identify, locate, and solve build errors efficiently.

After this lesson, you will be able to:

■ Locate and analyze build reports.

■ Diagnose and solve build issues.

Estimated lesson time: 15 minutes.

When you perform a build either in the Visual Studio IDE or the command prompt, the build process outputs a significant amount of build information. The build system tracks this information in a Build.log file. Details about compilation or linker warnings and errors also can be found in the Build.wrn and Build.err files. If you started a complete build or a Sysgen operation for an OS design by using one of the corresponding commands on the Build menu in Visual Studio, the build system writes these files in the %_WINCEROOT% folder (by default, C:\Wince600). On the other hand, if you perform a build for only a particular component, such as by right- clicking a subproject folder in Solution Explorer and clicking the Build command from the context menu, the build system writes these files in that specific directory. In either case, the Build.wrn and Build.err files only exist if you encounter warnings and errors during the build process. However, you do not need to open and parse through these files in Notepad or another plain-text editor. Visual Studio 2005 with Platform Builder for CE 6.0 R2 displays this information during the build process in the Output window. You can also examine status messages, warnings, and errors in the Error List window that you can display by clicking Error List, which is available under Other Windows on the View menu.

Figure 2-6 shows the Output window and the Error List window in undocked view. The Output window displays the Build.log content if you select Build from the Show Output From list box. The Error List window displays the contents Build.wrn and Build.err files.

Figure 2-6Output window and Error List window with build information in Visual Studio

Specifically, you can find the following information in the build log files:

■ Build.logContains information about the individual commands issued within each phase during the build process. This information is useful for analyzing both the build process in general, and build errors in particular.

■ Build.wrnContains information about warnings generated during the build process. If possible, try to eliminate or at least identify the reasons for the warnings. The information in Build.wrn is also included in Build.log.

■ Build.errContains specific information about build errors encountered during the build process. This information is also available with additional details in Build.log. This file is created only when an error occurs.

The build system keeps track of skipped and entered build phases in the Build.log file. For example, the entry CEBUILD: Skipping directly to SYSGEN phase indicates that the build system skipped the Compile phase for a component. You can determine where the Sysgen phase begins, how the build process transitions from SYSGEN to BUILD, and how BUILD eventually leads to MAKEIMG.