summaryrefslogtreecommitdiff
path: root/packaging
AgeCommit message (Collapse)Author
2025-01-09Merge "Define droidcore and droidcore-unbundled in sooong-only builds" into main Treehugger Robot
2025-01-09Define droidcore and droidcore-unbundled in sooong-only builds Cole Faust
Some modules register disted files against these phonies, and then they get disted when running `m droid dist` because they're dependencies of droid in make. Recreate this behavior in soong-only builds. Bug: 388312357 Test: m --soong-only dist dists acloud and aidegen Change-Id: I9f2300967752ce1564db44a552d41144ff40cffd
2025-01-09Remove goals warning Cole Faust
This was just a debug print that was mistakenly submitted. Bug: 388312357 Test: Presubmits Change-Id: Ie99e2061ef9167eab57bc039dc4145cf448161af
2025-01-08Support disting in soong-only builds Cole Faust
Disting was normally handled by the packaging kati step, which was not run in soong-only builds. Disting needs to be done in a separate ninja file, so that if you toggle dist on/off you only need to regenerate a small ninja file instead of the main one. This change makes it so that the kati packaging step is also run in soong-only builds. (which makes them not technically soong-only, but the packaging step is very fast so it's fine) Phonies in soong were normally exported to the main make invocation and then make would emit the ninja rules for them. In soong-only builds soong would emit the ninja phone rules directly. This is problematic when supporting disting in soong, because some of the phony rules have the same name as dist targets, causing ninja to complain about duplicate rules. To resolve this, make soong export its phonies to the packaging step, which will dedup them with the dist phonies. Bug: 388312357 Test: m --soong-only dist Change-Id: I1ebf164541173804a2c0c01a5a3b1b139fbf139b
2023-06-26Trace time spent in cp rules for dist targets. Dan Albert
Bug: http://b/259130368 Test: Used patched soong_trace.py to measure this Change-Id: Ic85e35ad17b18fb316770cdebc3e01f45edfab44
2023-05-23BUILD_NUMBER and BUILD_HOSTNAME doesn't affect kati regeneration Jeongik Cha
* Extract BUILD_NUMBER, BUILD_HOSTNAME to file to avoid kati change * Handle FILE_NAME_TAG_PLACEHOLDER string in dist in build/make/packaging/distdir.mk Test: check if kati isn't invoked even though BUILD_NUMBER, BUILD_HOSTNAME is changed Test: m && m, and check if the second m is no-op Bug: 278060169 Change-Id: I1b37760242853c1a145bad255d0bb15524234b25 Merged-In: I1b37760242853c1a145bad255d0bb15524234b25
2018-10-21Fix creating _dist_<goal> targets under !dist Dan Willemsen
I had initially thought that we would have created the rule when marking it as PHONY, but that's apparently not the case. Bug: 117463001 Test: m test-art-host-gtest Change-Id: I5e397423dfb138725db0e3e07b2630f8e872bb12
2018-10-20Create a new kati packaging step; move dist Dan Willemsen
Instead of looking at `dist` and DIST_DIR directly in the Kati Build step, always write out information about every call to dist, then create the rules in another ckati run. So instead of having: dist: <goal> -> <dist> -> <output> \______________↑ nodist: <goal> -----------> <output> Always use another phony target in the Kati Build step: <goal> ---> <output> \----> _dist_<goal> Then in the packaging step (which is much faster), choose between dist and no dist: dist: _dist_<goal> -> <dist> -> <output> nodist: _dist_<goal> Bug: 117463001 Test: m dist Change-Id: Ic96bb6356740300dd3113f6ed699e6a619360c40