EBuild Objects

EBuild Projects are made up of two types of items: Objects and Settings.

Objects represent the pieces that make up your project. These can be input files, references and more. Objects have a Kind and a Name, and you can have many objects of the same kind (e.g. multiple source files of the "Compile" kind).

Inside the project, objects can specified globally, or for a specific target.

How Objects are Maintained

At build time, EBuild maintains a flat space of known objects, with each object optionally being constrained to a specific target and/or configuration.

The initial set of objects is entirely driven by content from the project itself.

During build, tasks can add new objects, or amend existing objects with additional meta data.

Querying Objects

Objects are queried by Kind, either project wide or filtered to the current Target.

Object Kinds can be sub-categorized with a dash followed by an additional string, for example to distinguish between objects for a particular architecture or device type. For instance, while CompilerOutput is normally used as kind for the items returned from the Elements compile phase, on the Island platform, compiler output is separated by architecture, e.g. CompilerOutput-x86_64 or CompilerOutput-arm64.

Wildcards can be used to query for objects with subkinds, as the following examples show:

  • Objects["CompilerOutput"] would return only exact matches.
  • Objects["CompilerOutput-*"] would return "CompilerOutput" objects, as well as any sub-kinds (e.g. "CompilerOutput-arm64" and "CompilerOutput-x86_64").
  • Objects["CompilerOutput-|arm64"] would return "CompilerOutput" objects, as well as objects matching the exact sub-kind (e.g. "CompilerOutput-arm64" but not "CompilerOutput-x86_64").

Finally,

  • Objects["CompilerOutput*"] would return "CompilerOutput" objects, as well as any kind that starts with "CompilerOutputFoo".

Object Meta Data

Object Meta Data are string-based key-value pairs (following rules similar to Settings) that can be set on individual objects. These are free-form, and valid values depend on the specific object kinds.

However, a few meta data values have special meaning and/or are frequently used:

  • ResolvedPath refers to the actual path of the object on disk (if applicable to the Kind). If ResolvedPath is set, it must be valid and point to a file or folder that exists locally. This avoids extra unnecessary "if file exists" checks.
  • CopyLocal is a boolean flag indicating whether the object should be considered part of the final deliverable and copied to the output folder.
  • Ignored can be set to fully ignore an object in subsequent queries. Once ignored, an object will be excluded from any future queries.

See Also