Starboard currently uses GYP as the basis of its build system, though there is already some movement towards GN as a replacement.
While you can integrate Starboard into any build system, there are enough knobs and dials that it would be a daunting effort. Instead, Starboard tries to provide a functional build framework that an application developer can easily integrate with.
The basic flow of how Starboard builds is:
starboard/build/gyp
- Parse command line parameters and pass them intoGypRunner
.starboard/build/gyp_runner.py
- Load the
PlatformConfiguration
. - Load the
ApplicationConfiguration
. - Calculate and merge the GYP includes, GYP variables, environment variables, and generator variables, and pass them into GYP.
- Load the
- tools/gyp - Parse all the .gyp and included .gypi files, generate ninja.
- ninja - Build all the source files.
In this documentation, you will see a lot of discussion about things being Platform or Application concerns.
The Platform is more-or-less what you think it is -- Everything you might need to build any Starboard Application on a given platform.
It helps to think about an Application as a broader concept than a single program. From Starboard's build system's perspective, an Application is a single configuration of build variables per platform, which may produce many build targets beyond a single executable - shared libraries, tests, and so on.
Each Application will probably want to define its own knobs, dials, and defaults to be able to be customized per platform, and so Starboard provides a space for the Application to do that.
Each Application can provide a platform-specific ApplicationConfiguration
instance by creating a python module in
<platform-directory>/<application-name>/configuration.py
. This module must
contain a class definition that extends from
starboard.build.application_configuration.ApplicationConfiguration
. If the
class is not found in the platform-specific location, a generic configuration
will be loaded, as dictated by the APPLICATIONS
registry in
starboard_configuration.py
.
Additionally, the Application can provide a GYPI file to be included at
<platform-directory>/<application-name>/configuration.gypi
. This will, by
default, be included at the end of all other configuration GYPI files, but this
behavior can be arbitrarily customized by the loaded ApplicationConfiguration
class.
-
Create your Application's root
.gyp
file. Often calledall.gyp
or something similar. -
Create a cross-platform
ApplicationConfiguration
python class for your application. Take a look atcobalt_configuration.py
as an example.Define a subclass of
starboard.build.application_configuration.ApplicationConfiguration
and override any desired methods. -
Register your Application in your
starboard_configuration.py
file in your source tree root.To do this, just add an entry to the
APPLICATIONS
Mapping that maps your canonical Application name to the cross-platformApplicationConfiguration
subclass constructor for your application.APPLICATIONS = { # ... 'example_app': example_app.ExampleAppConfiguration # ... }
At this point, you should be able to build your application with:
starboard/build/gyp -a <application-name>