Platform builder compilation process

ZZ platform builder compilation process

After the last two learning sessions, we have created and can freely modify our own platform. This time, I will add some theoretical knowledge to help you better understand the CE generation process. Before that, it should be noted that the CE directory structure is very large and complex. In the future work, many things will depend on your understanding of the directory structure. Here, the folder structure of ce5 has not changed significantly. Therefore, if you want to know this part, you can directly refer to the relevant section of my "wince tutorial. A little different from Ce4 is that in ce5, your platform is not stored in the public folder, but a folder dedicated to pbworkspaces, which makes management easier and has a clear structure.
What we need to talk about is the CE generation process, that is, when you compile the platform, what did platform builder do for you?
In fact, IDE has gone through four phases in the CE generation process: sysgen, build, copy, and make, namely, component generation and compilation, the release folder copy and image packaging phases. Next we will explain it in stages.
In the public folder, there are available components provided by CE for us. We choose to customize our own platform through platform builder, where we select some required components. These folders contain all available library files, header files, Def files, and of course all exported function descriptions. In the sysgen stage, we need to select the header files required by our own platform, library files and export functions to create components required by our own platform. The header file is marked as a C ++ annotation, so that it can select the desired part for export, finally, link all the required libraries to get what our own platform needs, it is stored in the wince500 \ pbworkspaces \ % projectname % \ wince500 \ % cpu_type % _ x86 \ cesysgen folder.
After the last phase, the required header file library is ready, but this is only part of the system components. Our platform also has a variety of device drivers and other things, these will be completed in the build phase.
The entire build phase is centered around the dirs and sources files. The former determines which folders are to be compiled, and the latter determines how files are to be compiled. That is to say, at this stage, compilation of various source programs is required. Next we will focus on the content of these two types of files.
The dirs file can be found in many folders. It lists the subfolders to be compiled. The content is roughly as follows:

Dirs_ce = \
Ceddk \
Regenum \
Pcibus \

In this example, build.exe can be used to find the folder to be compiled layer by layer during compilation. The meanings of optional_dirs, dirs_ntansi, and other projects can be found through help.
Similarly, the sources file specifies the compilation method of the source program involved in compilation, for example, specifying the name after compilation through targetname and specifying whether the compiled type is exe, DLL or lib through targettype, use dllentry to specify the DLL file entry point, specify the header files required during the compilation process by using DES, and use sources to specify the source files involved in compilation. The usage of these macros is described in more detail in the help document. You only need to understand this compilation mechanism here.
Next, all the compilation is completed, DLL or EXE, all of which are self-built on the target platform. The next step is a copy process, that is, copy the content in the wince500 folder under your project folder to the release folder. There is nothing to say in this step.
The last step is to package the prepared files on the target platform into operating system image files such as NK. Bin. In this process, four sub-processes are completed: file merging, registry compression, resource file replacement, and packaging.
In the file merging phase, merge the following files:
-- Merge all. bib files into Ce. bib
-- Merge all. Reg files into reginit. ini
-- Merge all. DAT files into initobj. dat
-- Merge all. DB files into initdb. ini
After these merge operations, you can find out whether your modifications are actually placed on the target platform under release.
Registry compression compresses the reginit. Int file into the default. FDF file.
Resource Replacement is to replace resources in EXE or DLL with local languages such as simplified Chinese.
The following is the CE. bib and other binary files to make NK. binfile: This is the file we need. However, in ce5, it seems that you can change the file name in the Project Settings. You can try it on your own.
The above compilation process is clearly defined under the build OS menu in platform builder, which is much better than Ce4. You can let it execute a specific step on your own. If you modify the source program of a component, you can right-click the component and compile it separately, and then generate an image. In short, flexibility is quite good.
At the same time, after the above analysis, we can see that the IDE platform builder relies on the folder structure, those text files, and batch files to help generate Ce. Therefore, try to be familiar with the folder structure. At the same time, it also proves the ignorance of those who say that the batch processing files are useless. in Microsoft's operating systems and development tools, the batch processing files are crucial, people who say it is useless only because their own level is not enough.
Well, we have learned a little more this time, but it is still necessary to understand this knowledge. Don't forget to learn it against your folder structure!