Compile eclipse.

Download the eclipse source code package from www.eclipse.org and decompress it. .

Go to www.eclipse.org and check the build instruction. We found that the compilation is very simple, and ant is also used (fortunately ant, ^ _ ^ ). There is a build. the bat script requires passing several parameters based on different platforms:-OS OS,-ws window system,-arch CPU architecture, then, the build script selects different builds based on these parameters. XML file, and then call ant for compilation. For specific parameters, see the eclipse compilation help documentation. I use Windows XP, so the compilation parameter is build-OS Win32-ws Win32-arch x86.

Note that you must set the ant_home path before compiling. The simple method is to start the menu --> Run and input set ant_path = D:/Apache-ant-1.6.0. I suggest you set the ant bin directory TO THE PATH environment variable, because each plug-in of eclipse has a build. XML file. Most of the components can be directly compiled by hitting ant in its directory. If you modify part of the code of a component, you can simply input ant to observe the results without returning to the root directory for full compilation.

It should be said that the compilation process of eclipse itself is not too slow. On my P4 2.8/1g RAM machine, it will take 15 minutes. However, when I change some files of a plug-in and then return to the root directory for partial compilation, I find that it takes almost the same time to complete the compilation, because many plug-ins that haven't changed have also been re-compiled and packaged, which makes me feel very uncomfortable. I don't know why there is such a design. It seems that I need to analyze the eclipse build script.

After compilation, you will find a tmp sub-directory under the root directory. Below are three directories, plugins, features, and a directory that varies with the platform, in my system, this is called setup. x86. Plugins are all compiled plug-ins, and all the feature files are stored in features. Finally, the very difficult eclipse splash actually appeared, and then the entire program started, everything is OK.

In order to have a rational understanding of the entire compilation process, I tracked the entire eclipse compilation process and observed the call relationships between multiple builk. XML files.

1. the build. xml file in the root directory has a target named allelements. The script is as follows:
<Target name = "allelements">
<Ant antfile = "$ {builddirectory}/Features/org. eclipse. SDK/build. XML "target =" $ {target} "dir =" $ {builddirectory}/Features/org. eclipse. SDK "/>
</Target>
Obviously, the org. eclipse. build. XML file, and the target of execution is build. jar (to understand this attribute, read eclipse_src/build. XML ). All these scripts mean to execute ant build. jar in the features/org. Eclipse. SDK directory.

2. Analyze the scripts corresponding to build. jar in the org. Eclipse. SDK/build. xml file,
<Target name = "build. JARS" depends = "init" Description = "build all the jars for the feature: org. Eclipse. SDK.">
<Antcall target = "all. Children">
<Param name = "target" value = "build. JARS"/>
</Antcall>
</Target>
Keep following the depend of build. jar and keep track of all. features. Everything is clear.
<Target name = "all. Features" depends = "init">
<Ant antfile = "build. xml" dir = "../org. Eclipse. Platform/" target = "$ {target}"/>
<Ant antfile = "build. xml" dir = "../org. Eclipse. Platform. Source/" target = "$ {target}"/>
<Ant antfile = "build. xml" dir = "../org. Eclipse. jdt/" target = "$ {target}"/>
<Ant antfile = "build. xml" dir = "../org. Eclipse. jdt. Source/" target = "$ {target}"/>
<Ant antfile = "build. xml" dir = "../org. Eclipse. PVDF/" target = "$ {target}"/>
<Ant antfile = "build. xml" dir = "../org. Eclipse. PVDF. Source/" target = "$ {target}"/>
</Target>
Obviously, this target indicates compiling the build. xml file of the other six feature files under features. In addition, we can see the hierarchical relationship between Eclipse plug-ins. the SDK calls the build. xml of platform, jdt, and PDE, which clearly means these three plug-ins constitute the SDK.

3. the remaining tracking steps are the same as those above. Platform calls all build plug-ins that constitute platform. XML, jdt calls constitute the build of the jdt plug-in. for example, in features/org. eclipse. platform/build. A row in XML:
<Target name = "all. plugins" depends = "init">
<Ant antfile = "build. xml" dir = ".../../plugins/org. Eclipse. osgi" target = "$ {target}">
<Property name = "arch" value = "x86"/>
<Property name = "OS" value = "Win32"/>
<Property name = "ws" value = "Win32"/>
</Ant>
... Call other plug-ins
Obviously, every plug-in the Plugins directory is compiled in this way.

4. check the build of a specific plug-in. XML file, org. eclipse. core. runtime/build. A section in XML describes the entire compilation process. Of course, the packaging part is in another target:
<Target name = "runtime. Jar" depends = "init" Unless = "runtime. Jar" Description = "create jar: runtime. jar.">
<Delete dir = "$ {temp. Folder}/runtime. Jar. bin"/> // delete a temporary directory
<Mkdir dir = "$ {temp. Folder}/runtime. Jar. bin"/> // create a temporary directory
<! -- Compile the source code -->
// Compile all. java files. The source code directory is specified in the subsequent <SRC Path = "src"/>.
<Javac destdir = "$ {temp. folder}/runtime. jar. bin "failonerror =" $ {javacfailonerror} "verbose =" $ {javacverbose} "DEBUG =" $ {javacdebuginfo} "includeantruntime =" no "bootclasspath =" $ {bootclasspath }" = "$ {javacsource}" target = "$ {javactarget}">
<Compilerarg line = "$ {compilerarg}"/>
<Classpath>
<Pathelement Path = "$ {build. Result. Folder}/../org. Eclipse. osgi/CORE. Jar"/>
<Pathelement Path = "$ {build. Result. Folder}/../org. Eclipse. osgi/console. Jar"/>
<Pathelement Path = "$ {build. Result. Folder}/../org. Eclipse. osgi/osgi. Jar"/>
<Pathelement Path = "$ {build. Result. Folder}/../org. Eclipse. osgi/resolver. Jar"/>
<Pathelement Path = "$ {build. Result. Folder}/../org. Eclipse. osgi/defaultadaptor. Jar"/>
<Pathelement Path = "$ {build. Result. Folder}/../org. Eclipse. osgi/eclipseadaptor. Jar"/>
</Classpath>
<SRC Path = "src/"/>
</Javac>
<! -- Copy necessary resources -->
// Copy some non-code resource files.
<Copy todir = "$ {temp. Folder}/runtime. Jar. bin" failonerror = "true">
<Fileset dir = "src/" excludes = "**/*. Java, **/package.htm *"/>
</Copy>
// Package
<Mkdir dir = "$ {build. Result. Folder}"/>
<Jar jarfile = "$ {build. Result. Folder}/runtime. Jar" basedir = "$ {temp. Folder}/runtime. Jar. bin"/>
// Delete the temporary directory
<Delete dir = "$ {temp. Folder}/runtime. Jar. bin"/>
</Target>

The Analysis of eclipse has finally been completed, and my previous doubts have been lifted. When the build command is typed in the root directory of the eclipse source code, the compilation enters eclipse_src/build. XML's "compile" target. The first thing its brother needs to do is to execute the "init" and "clean" targets first, and then call allelements. The following script is used:
<Target name = "compile" depends = "init, clean">
Therefore, it can be said that eclipse does not have the concept of partial compilation. The only way to think about it is to enter the plug-in you want to re-compile and execute:
Ant clean
Ant build. Jar
Game over!