Confirmed users
429
edits
Gaia/Build/NewBuildSystem: Difference between revisions
no edit summary
Ricky Chien (talk | contribs) |
Ricky Chien (talk | contribs) No edit summary |
||
| Line 16: | Line 16: | ||
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 GNU make as our build back-end to produce final target. It means configure.js part 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 replace 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 GNU make as our build back-end to produce final target. It means configure.js part 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 replace 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 same PROFILE_DIR as usual. | * '''Deliverable:''' A new Gaia Makefile target to trigger configure.js modules should be landed in Gaia code base. The configure.js can generate an all.mk (a temporary new Makefile) and produce a same PROFILE_DIR as usual. | ||
* '''Expected schedule:''' 4 weeks | * '''Expected schedule:''' 4 weeks | ||
* '''Breakdowns:''' | * '''Breakdowns:''' | ||
** New config step: adding configure.js to generate strong dependency | ** New config step: adding configure.js to generate strong dependency all.mk and execute it. | ||
** New re-run step: in 2nd make, new build will check the change files and ENV to decide whether to regenerate | ** New re-run step: in 2nd make, new build will check the change files and ENV to decide whether to regenerate all.mk or not, and then execute it. | ||
** Refactoring webapp-shared.js and copyToStage: based on new build system architecture, we'll refactor webapp-shared module and copyToStage into config and execute task in order to save time when re-run make and check if any possible risk before Milestone 2 (refactoring all build modules and app/build.js). | ** Refactoring webapp-shared.js and copyToStage: based on new build system architecture, we'll refactor webapp-shared module and copyToStage into config and execute task in order to save time when re-run make and check if any possible risk before Milestone 2 (refactoring all build modules and app/build.js). | ||
== Milestone 2 == | == Milestone 2 == | ||
After initial landing step being done, we should abandon | After initial landing step being done, we should abandon GNU make's PHONY targets as many as possible, so we could have a faster build by taking the advantage of GNU make'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:''' | * '''Deliverable:''' Abandon GNU make's PHONY targets as many as possible to speed up incremental build and implement config.status phase. | ||
* '''Expected schedule:''' 6 - 8 | * '''Expected schedule:''' 6 - 8 weeks | ||
* '''Breakdowns:''' | * '''Breakdowns:''' | ||
** | ** Refactoring all modules and app/build.js into small tasks. It means split into configuring & building steps. | ||
** Implement config.status which will introduce DAG structure to configure step. | ** Implement config.status which will introduce DAG structure to configure step. | ||
== Milestone 3 == | == Milestone 3 == | ||
We're going to measure incremental build performance from | We're going to measure incremental build performance from GNU make back-end. If the result is as good as our expectation, the decision of choosing build back-end would be GNU make. Otherwise, the new milestone would be targeting on constructing the new build back-end tool. | ||
After surveying in milestone 3 of previous plan [https://wiki.mozilla.org/Gaia/Build/RefactoringToNodejs#Milestone_3 RefactoringToNode], we believe that the [http://gulpjs.com/ Gulp] or streaming base build back-end could offer a better performance especially in clobber build. Therefore, in this step, a streaming base build system which will be implemented. | After surveying in milestone 3 of previous plan [https://wiki.mozilla.org/Gaia/Build/RefactoringToNodejs#Milestone_3 RefactoringToNode], we believe that the [http://gulpjs.com/ Gulp] or streaming base build back-end could offer a better performance especially in clobber build. Therefore, in this step, a streaming base build system which will be implemented. | ||