Gaia/Build/NewBuildSystem: Difference between revisions

Jump to navigation Jump to search
Line 5: Line 5:
== Milestone 1 ==
== Milestone 1 ==


Initial landing stage. Since our new build system plan is around splitting a build process into two steps including configuring and building. This stage will focus on building up a configuration modules - configure.js and using GUN make as our build back-end to produce final target. It means configure.js module will run on XPCShell and require existed build modules at this stage in order to keep build system working properly. Finally, the new build system is going to be landed in code-base and coexist with current build system.
Initial landing step. Since our new build system plan is around splitting a build process into two steps including configuring and building. This stage will focus on building up a configuration modules - configure.js and using GUN make as our build back-end to produce final target. It means configure.js module will run on XPCShell and require existed build modules at this stage in order to keep build system working properly. Finally, the new build system is going to be landed in code-base and coexist with current build system.


* '''Deliverable:''' A new Makefile target to trigger configure.js modules should be landed in Gaia code base. The configure.js can generate a Makefile and produce a proper PROFILE_DIR.
* '''Deliverable:''' A new Makefile target to trigger configure.js modules should be landed in Gaia code base. The configure.js can generate a Makefile and produce a proper PROFILE_DIR.
Line 18: Line 18:
== Milestone 2 ==
== Milestone 2 ==


* '''Deliverable:''' TBD
After initial landing step being done, we should first introduce a new integration test suite for stabilization. Second thing is to abandon Makefile's PHONY targets as many as possible, so we could have a faster build by taking the advantage of Makefile's incremental build. Finally, configure.js should be able to connect with different build back-end. In order to achieve this aim, we eventually come out a new phase - config.status for preparing the next step (replacing build back-end). The idea of config.status is charged with
* '''Expected schedule:''' week
the task of tell back-end tool how to build the tree which includes scanning the build system definition and constructing a DAG data structure for representing task dependency and supporting parallel build natively.
 
* '''Deliverable:''' Stabilization & Efficient incremental build & Implement config.status
* '''Expected schedule:''' 6 - 8 week
* '''Breakdowns:'''
* '''Breakdowns:'''
# Enable build integration test Gbn (Gaia Build New) for new build system in treeherder
# Enable build integration test Gbn (Gaia Build New) in treeherder for new build system
# In order to abandon .PHONY targets, we should split all modules and app/build.js into small tasks. It means split into configuring & building steps.
# Split all modules and app/build.js into small tasks. It means split into configuring & building steps.
# Introduce DAG tree in configure.js architecture for supporting parallel build
# Implement config.status phase which includes scanning the build system definition and a DAG data structure for representing task dependency and supporting parallel build.
# Generate a config.status




== Milestone 3 ==
== Milestone 3 ==


* '''Deliverable:''' TBD
TBD
 
* '''Deliverable:''' A blazing fast JavaScript build system
* '''Expected schedule:''' week
* '''Expected schedule:''' week
* '''Breakdowns:'''
* '''Breakdowns:'''
#
# Implement a JavaScript build system as our build back-end tool instead of GNU make
Confirmed users
429

edits

Navigation menu