The EGL build path

EGL projects contain a build path, which lists EGL projects and EGLAR files that you want to reference from the current project.

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 that would mean duplicating 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, however, so you might need to import the part to bring it into scope.

A project build path includes the following items:

A list of EGL source folders in the current project
The location of the generated output folder, which is meaningful only for Java™ generation
Zero to many projects to include in the build path

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. See Editing the EGL build path.

The order of the items in the build path is significant because EGL searches for parts based on the order of the folders and projects in the build path. 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.

You can also choose to export a project or source folder in your build path. In this case, the exported project or source folder is available to all projects that refer to the current project. For example, take the following project build paths:

Project C
```
C, D, Y
```
Project D
```
D, E, Z
```

If, in the build path for project D, you choose to export project E but not project Z, the effective build path for project C is as follows:

C, D, E, Y

In this case, project D can use project Z, because Z is in D's build path. However, project C cannot use project Z because Z, is not exported along with project D. Project C can use project E, because project E is exported along with project D.

When working with multiple EGL projects, you should be careful not to create packages with identical names in two different projects. Also, you must 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 EGL build path.

In general, the build path information is stored in the .eglpath file in the root of the project. However, if you generate output code using the EGL SDK, the build path is determined through the command-line argument eglpath, which is a list of operating-system directories that are searched when the EGL SDK attempts to resolve a part reference. The eglpath argument behaves much like the .eglpath file except that you cannot export source folders with the eglpath argument as you can with the .eglpath file.