For example, suppose project A contains a Record part and you want to create a variable based on that Record part in project B. You could copy the source file from project A into project B, but by doing so, you would duplicate the file. Instead, you can add project A to the build path of project B. Then you can use the Record part in project B as though the definition were in project B. Scoping rules still apply, so you might need to import the part to bring it into scope.
Adding other projects to the build path is useful only while you are coding; for example, the EGL build path enables content assist to find other parts and insert correct import statements. The EGL build path also provides a way for validation to flag unknown parts and functions. If you are generating to Java, to allow your project to use parts in another project at run time, you must make that project available at run time. For more information, see "Editing the build path."
The order of the items in the build path is significant; EGL searches for parts based on the order of the folders and projects in the build path. For more information, see "Name resolution in an expression." For this reason, the source folders of the current project are usually the first items in the build path.
C, D, Y
D, E, Z
C, D, E, YIn this case, project D can use project Z, because Z is in the build path of D. However, project C cannot use project Z because Z is not exported with project D. Project C can use project E because project E is exported with project D.
When you work with multiple EGL projects, be careful not to create packages with identical names in two different projects. Also be careful to avoid circular references, that is, build paths that make an infinite loop.
To add or remove projects in the build path, or to set exporting for a project on the build path, see "Editing the build path."
The build path information is stored in the .eglpath file in the root of the project.