Gaia/Build/NewBuildSystem

Plan

After surveying, we decide to split build system into 2 steps: configure step and build step. For detailed information, please visit change proposal in dev-gaia Update on Gaia build changes: A configure step, and Make v.s. Gulp.

Our goal is to build up a robust build configuration being able to adopt any type of build back-end such as Make, Tup, Gulp...etc.

Milestone 1

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.
• Expected schedule: 4 week
• Breakdowns:

1. Create a configure.js modules to generate a proper profile
2. The configure.js should know whether it will re-run itself / all.mk or not in an incremental build
3. The configure.js will generate DAG for Makefile
4. The configure.js should read build config to re-generate DAG
5. Split webapp-shared into small tasks in order to get rid of .PHONY target and split copy app configuring step & building step

Milestone 2

After initial landing step being done, we should 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. The 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 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. It means config.status will be generated by configure.js and output a build-file for back-end consumption (e.g. a `make` back-end will write a `Makefile`).

• Deliverable: Stabilization & Efficient incremental build & Implement config.status
• Expected schedule: 6 - 8 week
• Breakdowns:

1. Split all modules and app/build.js into small tasks. It means split into configuring & building steps.
2. Implement config.status.

Milestone 3

TBD

• Deliverable: A blazing fast JavaScript build system
• Expected schedule: week
• Breakdowns:

1. Implement a JavaScript build system as our build back-end tool instead of GNU make