You can generate and deploy output from parts that are stored in the EGLAR file. In addition, you can use those parts to resolve references from EGL source code that is external to the EGLAR file. For example, the EGLAR file might include an Interface part, and you can use the definition to create a variable based on that part. Also, widget types that are defined in the EGLAR file can be displayed in the palette used by the EGL Rich UI editor.
The performance improvements affect compilation, generation, and indexing.
| Feature | Binary project | Stand-alone EGLAR file |
|---|---|---|
| Source code is available (read-only) | Yes | No, except for stand-alone functions |
| The EGL debugger can step into the code | Yes | No |
| The EGL software development kit (EGLSDK) can access the code | No | Yes |
The next sections give details on the two variations.
The stand-alone EGLAR file includes IR files as well as other resources such as graphics files and generated output. The EGLAR file cannot include source code, with the following, small exception: stand-alone function parts can be present. The lack of source code means that the debugger skips over the code as if the IR files were a generated output.
For details on setting the build path and on making the code in the EGLAR file available indirectly, see “Editing the EGL build path.” For details on setting the eglpath option to access the EGLAR file from the EGL software development kit (EGLSDK), see “EGLSDK.”
A stand-alone EGLAR file that is referenced from an EGL build path is available for part resolution or generation. If the file was not imported and you want to generate parts from that file, a default build descriptor is not available, and you must use the generation wizard. However, if the file was imported, a default build descriptor is available and is identified in the nearest embedding project, package, or folder.
A build-path reference to an EGLAR file in the file system has no effect on either the EGL or file search. Neither the parts list nor parts reference features of the workbench are available in relation to EGLAR files.
An export task configures a binary project from a non-binary project. That task includes the EGLAR file in the build path of the binary project and exports the EGLAR file so that projects that reference the binary project can access the EGLAR file.
Only one EGLAR file should be in the binary project. That EGLAR file includes only IR files, and the project always includes source code and can include resources such as generated output and graphics files.
You access a binary project by importing the project into your workspace. The binary project is then available for generation and deployment. Also, you can set the EGL build path of another project to access the binary project, for part resolution.
For details on setting the build path and on making the code in the binary project available indirectly, see “Editing the EGL build path.” Projects are not available to the EGL software development kit (EGLSDK).
If you generate parts from a binary project without using the generation wizard, the build descriptor is the default build descriptor in the binary project.
If you need to recreate the IR files in the binary project, update the source project on which the binary project is based and reexport that source project as a binary project. This action might be necessary if the binary project relies on the parts stored in a different source project, and some aspect of those parts changes.
Binary projects are included in both EGL searches and file searches.