platform_build_soong/cmd/soong_ui/main.go

722 lines
24 KiB
Go
Raw Normal View History

Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
// Copyright 2017 Google Inc. All rights reserved.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
package main
import (
"context"
Add --dumpvar[s]-mode to replace config.mk uses build/soong/soong_ui.bash --dumpvars-mode \ --vars="..." \ --abs-vars="..." \ --var-prefix="..." \ --abs-var-prefix="..." is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dump-many-vars \ DUMP_MANY_VARS="..." \ DUMP_MANY_ABS_VARS="..." \ DUMP_VAR_PREFIX="..." \ DUMP_ABS_VAR_PREFIX="..." and build/soong/soong_ui.bash --dumpvar-mode [--abs] VAR is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dumpvar-[abs-]-VAR But uses soong_ui and ckati, so that we use a consistent make parser and sandboxing configurations. One major output difference between the pure make implementation and this one is that report_config in Go is implemented using embedded newlines in single quotes, while the make implementation uses `` with embedded echo commands. This seems to work fine for both bash and zsh, and report_config isn't meant to be machine-parsed anyways. Test: build/soong/soong_ui.bash --dumpvar-mode report_config Test: build/soong/soong_ui.bash --dumpvar-mode TARGET_DEVICE Test: build/soong/soong_ui.bash --dumpvar-mode --abs PRODUCT_OUT Test: build/soong/soong_ui.bash --dumpvar-mode --abs ALL_PRODUCTS Test: build/soong/soong_ui.bash --dumpvars-mode --vars="report_config TARGET_DEVICE" --abs-vars="ALL_PRODUCTS" Test: build/soong/soong_ui.bash --dumpvars-mode --vars=TARGET_DEVICE --abs-vars=PRODUCT_OUT --var-prefix=v_ --abs-var-prefix=a_ Change-Id: I0fbd0732bbf6fcfcd24084cf3c830a91a4b6bfc2
2017-07-14 20:29:29 +02:00
"flag"
"fmt"
"io/ioutil"
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
"os"
"path/filepath"
"strconv"
"strings"
"syscall"
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
"time"
"android/soong/shared"
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
"android/soong/ui/build"
"android/soong/ui/logger"
"android/soong/ui/metrics"
"android/soong/ui/signal"
Add a unified status reporting UI This adds a new status package that merges the running of "actions" (ninja calls them edges) of multiple tools into one view of the current state, and gives that to a number of different outputs. For inputs: Kati's output parser has been rewritten (and moved) to map onto the StartAction/FinishAction API. A byproduct of this is that the build servers should be able to extract errors from Kati better, since they look like the errors that Ninja used to write. Ninja is no longer directly connected to the terminal, but its output is read via the protobuf frontend API, so it's just another tool whose output becomes merged together. multiproduct_kati loses its custom status routines, and uses the common one instead. For outputs: The primary output is the ui/terminal.Status type, which along with ui/terminal.Writer now controls everything about the terminal output. Today, this doesn't really change any behaviors, but having all terminal output going through here allows a more complicated (multi-line / full window) status display in the future. The tracer acts as an output of the status package, tracing all the action start / finish events. This replaces reading the .ninja_log file, so it now properly handles multiple output files from a single action. A new rotated log file (out/error.log, or out/dist/logs/error.log) just contains a description of all of the errors that happened during the current build. Another new compressed and rotated log file (out/verbose.log.gz, or out/dist/logs/verbose.log.gz) contains the full verbose (showcommands) log of every execution run by the build. Since this is now written on every build, the showcommands argument is now ignored -- if you want to get the commands run, look at the log file after the build. Test: m Test: <built-in tests> Test: NINJA_ARGS="-t list" m Test: check the build.trace.gz Test: check the new log files Change-Id: If1d8994890d43ef68f65aa10ddd8e6e06dc7013a
2018-05-18 01:37:09 +02:00
"android/soong/ui/status"
"android/soong/ui/terminal"
"android/soong/ui/tracer"
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
)
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
// A command represents an operation to be executed in the soong build
// system.
type command struct {
// The flag name (must have double dashes).
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
flag string
// Description for the flag (to display when running help).
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
description string
// Stream the build status output into the simple terminal mode.
simpleOutput bool
// Sets a prefix string to use for filenames of log files.
logsPrefix string
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
// Creates the build configuration based on the args and build context.
config func(ctx build.Context, args ...string) build.Config
// Returns what type of IO redirection this Command requires.
stdio func() terminal.StdioInterface
// run the command
run func(ctx build.Context, config build.Config, args []string)
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
}
// list of supported commands (flags) supported by soong ui
var commands = []command{
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
{
flag: "--make-mode",
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
description: "build the modules by the target name (i.e. soong_docs)",
config: build.NewConfig,
stdio: stdio,
run: runMake,
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
}, {
flag: "--dumpvar-mode",
description: "print the value of the legacy make variable VAR to stdout",
simpleOutput: true,
logsPrefix: "dumpvars-",
config: dumpVarConfig,
stdio: customStdio,
run: dumpVar,
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
}, {
flag: "--dumpvars-mode",
description: "dump the values of one or more legacy make variables, in shell syntax",
simpleOutput: true,
logsPrefix: "dumpvars-",
config: dumpVarConfig,
stdio: customStdio,
run: dumpVars,
}, {
flag: "--build-mode",
description: "build modules based on the specified build action",
config: buildActionConfig,
stdio: stdio,
run: runMake,
}, {
flag: "--finalize-bazel-metrics",
description: "finalize b metrics and upload",
config: build.UploadOnlyConfig,
stdio: stdio,
// Finalize-bazel-metrics mode updates metrics files and calls the metrics
// uploader. This marks the end of a b invocation.
run: finalizeBazelMetrics,
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
},
}
// indexList returns the index of first found s. -1 is return if s is not
// found.
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
func indexList(s string, list []string) int {
for i, l := range list {
if l == s {
return i
}
}
return -1
}
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
// inList returns true if one or more of s is in the list.
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
func inList(s string, list []string) bool {
return indexList(s, list) != -1
}
func deleteStaleMetrics(metricsFilePathSlice []string) error {
for _, metricsFilePath := range metricsFilePathSlice {
if err := os.Remove(metricsFilePath); err != nil && !os.IsNotExist(err) {
return fmt.Errorf("Failed to remove %s\nError message: %w", metricsFilePath, err)
}
}
return nil
}
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
// Main execution of soong_ui. The command format is as follows:
//
// soong_ui <command> [<arg 1> <arg 2> ... <arg n>]
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
//
// Command is the type of soong_ui execution. Only one type of
// execution is specified. The args are specific to the command.
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
func main() {
shared.ReexecWithDelveMaybe(os.Getenv("SOONG_UI_DELVE"), shared.ResolveDelveBinary())
buildStarted := time.Now()
c, args, err := getCommand(os.Args)
if err != nil {
fmt.Fprintf(os.Stderr, "Error parsing `soong` args: %s.\n", err)
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
os.Exit(1)
}
// Create a terminal output that mimics Ninja's.
output := terminal.NewStatusOutput(c.stdio().Stdout(), os.Getenv("NINJA_STATUS"), c.simpleOutput,
build.OsEnvironment().IsEnvTrue("ANDROID_QUIET_BUILD"),
build.OsEnvironment().IsEnvTrue("SOONG_UI_ANSI_OUTPUT"))
Add a unified status reporting UI This adds a new status package that merges the running of "actions" (ninja calls them edges) of multiple tools into one view of the current state, and gives that to a number of different outputs. For inputs: Kati's output parser has been rewritten (and moved) to map onto the StartAction/FinishAction API. A byproduct of this is that the build servers should be able to extract errors from Kati better, since they look like the errors that Ninja used to write. Ninja is no longer directly connected to the terminal, but its output is read via the protobuf frontend API, so it's just another tool whose output becomes merged together. multiproduct_kati loses its custom status routines, and uses the common one instead. For outputs: The primary output is the ui/terminal.Status type, which along with ui/terminal.Writer now controls everything about the terminal output. Today, this doesn't really change any behaviors, but having all terminal output going through here allows a more complicated (multi-line / full window) status display in the future. The tracer acts as an output of the status package, tracing all the action start / finish events. This replaces reading the .ninja_log file, so it now properly handles multiple output files from a single action. A new rotated log file (out/error.log, or out/dist/logs/error.log) just contains a description of all of the errors that happened during the current build. Another new compressed and rotated log file (out/verbose.log.gz, or out/dist/logs/verbose.log.gz) contains the full verbose (showcommands) log of every execution run by the build. Since this is now written on every build, the showcommands argument is now ignored -- if you want to get the commands run, look at the log file after the build. Test: m Test: <built-in tests> Test: NINJA_ARGS="-t list" m Test: check the build.trace.gz Test: check the new log files Change-Id: If1d8994890d43ef68f65aa10ddd8e6e06dc7013a
2018-05-18 01:37:09 +02:00
// Create and start a new metric record.
met := metrics.New()
met.SetBuildDateTime(buildStarted)
met.SetBuildCommand(os.Args)
// Attach a new logger instance to the terminal output.
log := logger.NewWithMetrics(output, met)
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
defer log.Cleanup()
// Create a context to simplify the program termination process.
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
ctx, cancel := context.WithCancel(context.Background())
defer cancel()
// Create a new trace file writer, making it log events to the log instance.
trace := tracer.New(log)
defer trace.Close()
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
// Create a new Status instance, which manages action counts and event output channels.
Add a unified status reporting UI This adds a new status package that merges the running of "actions" (ninja calls them edges) of multiple tools into one view of the current state, and gives that to a number of different outputs. For inputs: Kati's output parser has been rewritten (and moved) to map onto the StartAction/FinishAction API. A byproduct of this is that the build servers should be able to extract errors from Kati better, since they look like the errors that Ninja used to write. Ninja is no longer directly connected to the terminal, but its output is read via the protobuf frontend API, so it's just another tool whose output becomes merged together. multiproduct_kati loses its custom status routines, and uses the common one instead. For outputs: The primary output is the ui/terminal.Status type, which along with ui/terminal.Writer now controls everything about the terminal output. Today, this doesn't really change any behaviors, but having all terminal output going through here allows a more complicated (multi-line / full window) status display in the future. The tracer acts as an output of the status package, tracing all the action start / finish events. This replaces reading the .ninja_log file, so it now properly handles multiple output files from a single action. A new rotated log file (out/error.log, or out/dist/logs/error.log) just contains a description of all of the errors that happened during the current build. Another new compressed and rotated log file (out/verbose.log.gz, or out/dist/logs/verbose.log.gz) contains the full verbose (showcommands) log of every execution run by the build. Since this is now written on every build, the showcommands argument is now ignored -- if you want to get the commands run, look at the log file after the build. Test: m Test: <built-in tests> Test: NINJA_ARGS="-t list" m Test: check the build.trace.gz Test: check the new log files Change-Id: If1d8994890d43ef68f65aa10ddd8e6e06dc7013a
2018-05-18 01:37:09 +02:00
stat := &status.Status{}
// Hook up the terminal output and tracer to Status.
stat.AddOutput(output)
Add a unified status reporting UI This adds a new status package that merges the running of "actions" (ninja calls them edges) of multiple tools into one view of the current state, and gives that to a number of different outputs. For inputs: Kati's output parser has been rewritten (and moved) to map onto the StartAction/FinishAction API. A byproduct of this is that the build servers should be able to extract errors from Kati better, since they look like the errors that Ninja used to write. Ninja is no longer directly connected to the terminal, but its output is read via the protobuf frontend API, so it's just another tool whose output becomes merged together. multiproduct_kati loses its custom status routines, and uses the common one instead. For outputs: The primary output is the ui/terminal.Status type, which along with ui/terminal.Writer now controls everything about the terminal output. Today, this doesn't really change any behaviors, but having all terminal output going through here allows a more complicated (multi-line / full window) status display in the future. The tracer acts as an output of the status package, tracing all the action start / finish events. This replaces reading the .ninja_log file, so it now properly handles multiple output files from a single action. A new rotated log file (out/error.log, or out/dist/logs/error.log) just contains a description of all of the errors that happened during the current build. Another new compressed and rotated log file (out/verbose.log.gz, or out/dist/logs/verbose.log.gz) contains the full verbose (showcommands) log of every execution run by the build. Since this is now written on every build, the showcommands argument is now ignored -- if you want to get the commands run, look at the log file after the build. Test: m Test: <built-in tests> Test: NINJA_ARGS="-t list" m Test: check the build.trace.gz Test: check the new log files Change-Id: If1d8994890d43ef68f65aa10ddd8e6e06dc7013a
2018-05-18 01:37:09 +02:00
stat.AddOutput(trace.StatusTracer())
// Set up a cleanup procedure in case the normal termination process doesn't work.
signal.SetupSignals(log, cancel, func() {
trace.Close()
log.Cleanup()
Add a unified status reporting UI This adds a new status package that merges the running of "actions" (ninja calls them edges) of multiple tools into one view of the current state, and gives that to a number of different outputs. For inputs: Kati's output parser has been rewritten (and moved) to map onto the StartAction/FinishAction API. A byproduct of this is that the build servers should be able to extract errors from Kati better, since they look like the errors that Ninja used to write. Ninja is no longer directly connected to the terminal, but its output is read via the protobuf frontend API, so it's just another tool whose output becomes merged together. multiproduct_kati loses its custom status routines, and uses the common one instead. For outputs: The primary output is the ui/terminal.Status type, which along with ui/terminal.Writer now controls everything about the terminal output. Today, this doesn't really change any behaviors, but having all terminal output going through here allows a more complicated (multi-line / full window) status display in the future. The tracer acts as an output of the status package, tracing all the action start / finish events. This replaces reading the .ninja_log file, so it now properly handles multiple output files from a single action. A new rotated log file (out/error.log, or out/dist/logs/error.log) just contains a description of all of the errors that happened during the current build. Another new compressed and rotated log file (out/verbose.log.gz, or out/dist/logs/verbose.log.gz) contains the full verbose (showcommands) log of every execution run by the build. Since this is now written on every build, the showcommands argument is now ignored -- if you want to get the commands run, look at the log file after the build. Test: m Test: <built-in tests> Test: NINJA_ARGS="-t list" m Test: check the build.trace.gz Test: check the new log files Change-Id: If1d8994890d43ef68f65aa10ddd8e6e06dc7013a
2018-05-18 01:37:09 +02:00
stat.Finish()
})
criticalPath := status.NewCriticalPath()
buildCtx := build.Context{ContextImpl: &build.ContextImpl{
Context: ctx,
Logger: log,
Metrics: met,
Tracer: trace,
Writer: output,
Status: stat,
CriticalPath: criticalPath,
}}
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
config := c.config(buildCtx, args...)
config.SetLogsPrefix(c.logsPrefix)
logsDir := config.LogsDir()
buildStarted = config.BuildStartedTimeOrDefault(buildStarted)
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
buildErrorFile := filepath.Join(logsDir, c.logsPrefix+"build_error")
soongMetricsFile := filepath.Join(logsDir, c.logsPrefix+"soong_metrics")
rbeMetricsFile := filepath.Join(logsDir, c.logsPrefix+"rbe_metrics.pb")
bp2buildMetricsFile := filepath.Join(logsDir, c.logsPrefix+"bp2build_metrics.pb")
bazelMetricsFile := filepath.Join(logsDir, c.logsPrefix+"bazel_metrics.pb")
soongBuildMetricsFile := filepath.Join(logsDir, c.logsPrefix+"soong_build_metrics.pb")
metricsFiles := []string{
buildErrorFile, // build error strings
rbeMetricsFile, // high level metrics related to remote build execution.
bp2buildMetricsFile, // high level metrics related to bp2build.
soongMetricsFile, // high level metrics related to this build system.
bazelMetricsFile, // high level metrics related to bazel execution
soongBuildMetricsFile, // high level metrics related to soong build(except bp2build)
config.BazelMetricsDir(), // directory that contains a set of bazel metrics.
}
os.MkdirAll(logsDir, 0777)
log.SetOutput(filepath.Join(logsDir, c.logsPrefix+"soong.log"))
trace.SetOutput(filepath.Join(logsDir, c.logsPrefix+"build.trace"))
log.Verbose("Command Line: ")
for i, arg := range os.Args {
log.Verbosef(" [%d] %s", i, arg)
}
defer func() {
stat.Finish()
criticalPath.WriteToMetrics(met)
met.Dump(soongMetricsFile)
if !config.SkipMetricsUpload() {
build.UploadMetrics(buildCtx, config, c.simpleOutput, buildStarted, metricsFiles...)
}
}()
c.run(buildCtx, config, args)
}
func logAndSymlinkSetup(buildCtx build.Context, config build.Config) {
log := buildCtx.ContextImpl.Logger
logsPrefix := config.GetLogsPrefix()
build.SetupOutDir(buildCtx, config)
logsDir := config.LogsDir()
// Common list of metric file definition.
buildErrorFile := filepath.Join(logsDir, logsPrefix+"build_error")
rbeMetricsFile := filepath.Join(logsDir, logsPrefix+"rbe_metrics.pb")
soongMetricsFile := filepath.Join(logsDir, logsPrefix+"soong_metrics")
bp2buildMetricsFile := filepath.Join(logsDir, logsPrefix+"bp2build_metrics.pb")
soongBuildMetricsFile := filepath.Join(logsDir, logsPrefix+"soong_build_metrics.pb")
bazelMetricsFile := filepath.Join(logsDir, logsPrefix+"bazel_metrics.pb")
//Delete the stale metrics files
staleFileSlice := []string{buildErrorFile, rbeMetricsFile, soongMetricsFile, bp2buildMetricsFile, soongBuildMetricsFile, bazelMetricsFile}
if err := deleteStaleMetrics(staleFileSlice); err != nil {
log.Fatalln(err)
}
build.PrintOutDirWarning(buildCtx, config)
stat := buildCtx.Status
stat.AddOutput(status.NewVerboseLog(log, filepath.Join(logsDir, logsPrefix+"verbose.log")))
stat.AddOutput(status.NewErrorLog(log, filepath.Join(logsDir, logsPrefix+"error.log")))
stat.AddOutput(status.NewProtoErrorLog(log, buildErrorFile))
stat.AddOutput(status.NewCriticalPathLogger(log, buildCtx.CriticalPath))
stat.AddOutput(status.NewBuildProgressLog(log, filepath.Join(logsDir, logsPrefix+"build_progress.pb")))
Add a unified status reporting UI This adds a new status package that merges the running of "actions" (ninja calls them edges) of multiple tools into one view of the current state, and gives that to a number of different outputs. For inputs: Kati's output parser has been rewritten (and moved) to map onto the StartAction/FinishAction API. A byproduct of this is that the build servers should be able to extract errors from Kati better, since they look like the errors that Ninja used to write. Ninja is no longer directly connected to the terminal, but its output is read via the protobuf frontend API, so it's just another tool whose output becomes merged together. multiproduct_kati loses its custom status routines, and uses the common one instead. For outputs: The primary output is the ui/terminal.Status type, which along with ui/terminal.Writer now controls everything about the terminal output. Today, this doesn't really change any behaviors, but having all terminal output going through here allows a more complicated (multi-line / full window) status display in the future. The tracer acts as an output of the status package, tracing all the action start / finish events. This replaces reading the .ninja_log file, so it now properly handles multiple output files from a single action. A new rotated log file (out/error.log, or out/dist/logs/error.log) just contains a description of all of the errors that happened during the current build. Another new compressed and rotated log file (out/verbose.log.gz, or out/dist/logs/verbose.log.gz) contains the full verbose (showcommands) log of every execution run by the build. Since this is now written on every build, the showcommands argument is now ignored -- if you want to get the commands run, look at the log file after the build. Test: m Test: <built-in tests> Test: NINJA_ARGS="-t list" m Test: check the build.trace.gz Test: check the new log files Change-Id: If1d8994890d43ef68f65aa10ddd8e6e06dc7013a
2018-05-18 01:37:09 +02:00
buildCtx.Verbosef("Detected %.3v GB total RAM", float32(config.TotalRAM())/(1024*1024*1024))
buildCtx.Verbosef("Parallelism (local/remote/highmem): %v/%v/%v",
config.Parallel(), config.RemoteParallel(), config.HighmemParallel())
setMaxFiles(buildCtx)
defer build.CheckProdCreds(buildCtx, config)
// Read the time at the starting point.
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
if start, ok := os.LookupEnv("TRACE_BEGIN_SOONG"); ok {
// soong_ui.bash uses the date command's %N (nanosec) flag when getting the start time,
// which Darwin doesn't support. Check if it was executed properly before parsing the value.
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
if !strings.HasSuffix(start, "N") {
if start_time, err := strconv.ParseUint(start, 10, 64); err == nil {
log.Verbosef("Took %dms to start up.",
time.Since(time.Unix(0, int64(start_time))).Nanoseconds()/time.Millisecond.Nanoseconds())
buildCtx.CompleteTrace(metrics.RunSetupTool, "startup", start_time, uint64(time.Now().UnixNano()))
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
}
}
if executable, err := os.Executable(); err == nil {
buildCtx.ContextImpl.Tracer.ImportMicrofactoryLog(filepath.Join(filepath.Dir(executable), "."+filepath.Base(executable)+".trace"))
}
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
}
// Fix up the source tree due to a repo bug where it doesn't remove
// linkfiles that have been removed
fixBadDanglingLink(buildCtx, "hardware/qcom/sdm710/Android.bp")
fixBadDanglingLink(buildCtx, "hardware/qcom/sdm710/Android.mk")
// Create a source finder.
f := build.NewSourceFinder(buildCtx, config)
defer f.Shutdown()
build.FindSources(buildCtx, config, f)
Add --dumpvar[s]-mode to replace config.mk uses build/soong/soong_ui.bash --dumpvars-mode \ --vars="..." \ --abs-vars="..." \ --var-prefix="..." \ --abs-var-prefix="..." is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dump-many-vars \ DUMP_MANY_VARS="..." \ DUMP_MANY_ABS_VARS="..." \ DUMP_VAR_PREFIX="..." \ DUMP_ABS_VAR_PREFIX="..." and build/soong/soong_ui.bash --dumpvar-mode [--abs] VAR is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dumpvar-[abs-]-VAR But uses soong_ui and ckati, so that we use a consistent make parser and sandboxing configurations. One major output difference between the pure make implementation and this one is that report_config in Go is implemented using embedded newlines in single quotes, while the make implementation uses `` with embedded echo commands. This seems to work fine for both bash and zsh, and report_config isn't meant to be machine-parsed anyways. Test: build/soong/soong_ui.bash --dumpvar-mode report_config Test: build/soong/soong_ui.bash --dumpvar-mode TARGET_DEVICE Test: build/soong/soong_ui.bash --dumpvar-mode --abs PRODUCT_OUT Test: build/soong/soong_ui.bash --dumpvar-mode --abs ALL_PRODUCTS Test: build/soong/soong_ui.bash --dumpvars-mode --vars="report_config TARGET_DEVICE" --abs-vars="ALL_PRODUCTS" Test: build/soong/soong_ui.bash --dumpvars-mode --vars=TARGET_DEVICE --abs-vars=PRODUCT_OUT --var-prefix=v_ --abs-var-prefix=a_ Change-Id: I0fbd0732bbf6fcfcd24084cf3c830a91a4b6bfc2
2017-07-14 20:29:29 +02:00
}
func fixBadDanglingLink(ctx build.Context, name string) {
_, err := os.Lstat(name)
if err != nil {
return
}
_, err = os.Stat(name)
if os.IsNotExist(err) {
err = os.Remove(name)
if err != nil {
ctx.Fatalf("Failed to remove dangling link %q: %v", name, err)
}
}
}
func dumpVar(ctx build.Context, config build.Config, args []string) {
logAndSymlinkSetup(ctx, config)
Add --dumpvar[s]-mode to replace config.mk uses build/soong/soong_ui.bash --dumpvars-mode \ --vars="..." \ --abs-vars="..." \ --var-prefix="..." \ --abs-var-prefix="..." is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dump-many-vars \ DUMP_MANY_VARS="..." \ DUMP_MANY_ABS_VARS="..." \ DUMP_VAR_PREFIX="..." \ DUMP_ABS_VAR_PREFIX="..." and build/soong/soong_ui.bash --dumpvar-mode [--abs] VAR is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dumpvar-[abs-]-VAR But uses soong_ui and ckati, so that we use a consistent make parser and sandboxing configurations. One major output difference between the pure make implementation and this one is that report_config in Go is implemented using embedded newlines in single quotes, while the make implementation uses `` with embedded echo commands. This seems to work fine for both bash and zsh, and report_config isn't meant to be machine-parsed anyways. Test: build/soong/soong_ui.bash --dumpvar-mode report_config Test: build/soong/soong_ui.bash --dumpvar-mode TARGET_DEVICE Test: build/soong/soong_ui.bash --dumpvar-mode --abs PRODUCT_OUT Test: build/soong/soong_ui.bash --dumpvar-mode --abs ALL_PRODUCTS Test: build/soong/soong_ui.bash --dumpvars-mode --vars="report_config TARGET_DEVICE" --abs-vars="ALL_PRODUCTS" Test: build/soong/soong_ui.bash --dumpvars-mode --vars=TARGET_DEVICE --abs-vars=PRODUCT_OUT --var-prefix=v_ --abs-var-prefix=a_ Change-Id: I0fbd0732bbf6fcfcd24084cf3c830a91a4b6bfc2
2017-07-14 20:29:29 +02:00
flags := flag.NewFlagSet("dumpvar", flag.ExitOnError)
flags.SetOutput(ctx.Writer)
Add --dumpvar[s]-mode to replace config.mk uses build/soong/soong_ui.bash --dumpvars-mode \ --vars="..." \ --abs-vars="..." \ --var-prefix="..." \ --abs-var-prefix="..." is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dump-many-vars \ DUMP_MANY_VARS="..." \ DUMP_MANY_ABS_VARS="..." \ DUMP_VAR_PREFIX="..." \ DUMP_ABS_VAR_PREFIX="..." and build/soong/soong_ui.bash --dumpvar-mode [--abs] VAR is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dumpvar-[abs-]-VAR But uses soong_ui and ckati, so that we use a consistent make parser and sandboxing configurations. One major output difference between the pure make implementation and this one is that report_config in Go is implemented using embedded newlines in single quotes, while the make implementation uses `` with embedded echo commands. This seems to work fine for both bash and zsh, and report_config isn't meant to be machine-parsed anyways. Test: build/soong/soong_ui.bash --dumpvar-mode report_config Test: build/soong/soong_ui.bash --dumpvar-mode TARGET_DEVICE Test: build/soong/soong_ui.bash --dumpvar-mode --abs PRODUCT_OUT Test: build/soong/soong_ui.bash --dumpvar-mode --abs ALL_PRODUCTS Test: build/soong/soong_ui.bash --dumpvars-mode --vars="report_config TARGET_DEVICE" --abs-vars="ALL_PRODUCTS" Test: build/soong/soong_ui.bash --dumpvars-mode --vars=TARGET_DEVICE --abs-vars=PRODUCT_OUT --var-prefix=v_ --abs-var-prefix=a_ Change-Id: I0fbd0732bbf6fcfcd24084cf3c830a91a4b6bfc2
2017-07-14 20:29:29 +02:00
flags.Usage = func() {
fmt.Fprintf(ctx.Writer, "usage: %s --dumpvar-mode [--abs] <VAR>\n\n", os.Args[0])
fmt.Fprintln(ctx.Writer, "In dumpvar mode, print the value of the legacy make variable VAR to stdout")
fmt.Fprintln(ctx.Writer, "")
Add --dumpvar[s]-mode to replace config.mk uses build/soong/soong_ui.bash --dumpvars-mode \ --vars="..." \ --abs-vars="..." \ --var-prefix="..." \ --abs-var-prefix="..." is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dump-many-vars \ DUMP_MANY_VARS="..." \ DUMP_MANY_ABS_VARS="..." \ DUMP_VAR_PREFIX="..." \ DUMP_ABS_VAR_PREFIX="..." and build/soong/soong_ui.bash --dumpvar-mode [--abs] VAR is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dumpvar-[abs-]-VAR But uses soong_ui and ckati, so that we use a consistent make parser and sandboxing configurations. One major output difference between the pure make implementation and this one is that report_config in Go is implemented using embedded newlines in single quotes, while the make implementation uses `` with embedded echo commands. This seems to work fine for both bash and zsh, and report_config isn't meant to be machine-parsed anyways. Test: build/soong/soong_ui.bash --dumpvar-mode report_config Test: build/soong/soong_ui.bash --dumpvar-mode TARGET_DEVICE Test: build/soong/soong_ui.bash --dumpvar-mode --abs PRODUCT_OUT Test: build/soong/soong_ui.bash --dumpvar-mode --abs ALL_PRODUCTS Test: build/soong/soong_ui.bash --dumpvars-mode --vars="report_config TARGET_DEVICE" --abs-vars="ALL_PRODUCTS" Test: build/soong/soong_ui.bash --dumpvars-mode --vars=TARGET_DEVICE --abs-vars=PRODUCT_OUT --var-prefix=v_ --abs-var-prefix=a_ Change-Id: I0fbd0732bbf6fcfcd24084cf3c830a91a4b6bfc2
2017-07-14 20:29:29 +02:00
fmt.Fprintln(ctx.Writer, "'report_config' is a special case that prints the human-readable config banner")
fmt.Fprintln(ctx.Writer, "from the beginning of the build.")
fmt.Fprintln(ctx.Writer, "")
Add --dumpvar[s]-mode to replace config.mk uses build/soong/soong_ui.bash --dumpvars-mode \ --vars="..." \ --abs-vars="..." \ --var-prefix="..." \ --abs-var-prefix="..." is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dump-many-vars \ DUMP_MANY_VARS="..." \ DUMP_MANY_ABS_VARS="..." \ DUMP_VAR_PREFIX="..." \ DUMP_ABS_VAR_PREFIX="..." and build/soong/soong_ui.bash --dumpvar-mode [--abs] VAR is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dumpvar-[abs-]-VAR But uses soong_ui and ckati, so that we use a consistent make parser and sandboxing configurations. One major output difference between the pure make implementation and this one is that report_config in Go is implemented using embedded newlines in single quotes, while the make implementation uses `` with embedded echo commands. This seems to work fine for both bash and zsh, and report_config isn't meant to be machine-parsed anyways. Test: build/soong/soong_ui.bash --dumpvar-mode report_config Test: build/soong/soong_ui.bash --dumpvar-mode TARGET_DEVICE Test: build/soong/soong_ui.bash --dumpvar-mode --abs PRODUCT_OUT Test: build/soong/soong_ui.bash --dumpvar-mode --abs ALL_PRODUCTS Test: build/soong/soong_ui.bash --dumpvars-mode --vars="report_config TARGET_DEVICE" --abs-vars="ALL_PRODUCTS" Test: build/soong/soong_ui.bash --dumpvars-mode --vars=TARGET_DEVICE --abs-vars=PRODUCT_OUT --var-prefix=v_ --abs-var-prefix=a_ Change-Id: I0fbd0732bbf6fcfcd24084cf3c830a91a4b6bfc2
2017-07-14 20:29:29 +02:00
flags.PrintDefaults()
}
abs := flags.Bool("abs", false, "Print the absolute path of the value")
flags.Parse(args)
if flags.NArg() != 1 {
flags.Usage()
ctx.Fatalf("Invalid usage")
Add --dumpvar[s]-mode to replace config.mk uses build/soong/soong_ui.bash --dumpvars-mode \ --vars="..." \ --abs-vars="..." \ --var-prefix="..." \ --abs-var-prefix="..." is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dump-many-vars \ DUMP_MANY_VARS="..." \ DUMP_MANY_ABS_VARS="..." \ DUMP_VAR_PREFIX="..." \ DUMP_ABS_VAR_PREFIX="..." and build/soong/soong_ui.bash --dumpvar-mode [--abs] VAR is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dumpvar-[abs-]-VAR But uses soong_ui and ckati, so that we use a consistent make parser and sandboxing configurations. One major output difference between the pure make implementation and this one is that report_config in Go is implemented using embedded newlines in single quotes, while the make implementation uses `` with embedded echo commands. This seems to work fine for both bash and zsh, and report_config isn't meant to be machine-parsed anyways. Test: build/soong/soong_ui.bash --dumpvar-mode report_config Test: build/soong/soong_ui.bash --dumpvar-mode TARGET_DEVICE Test: build/soong/soong_ui.bash --dumpvar-mode --abs PRODUCT_OUT Test: build/soong/soong_ui.bash --dumpvar-mode --abs ALL_PRODUCTS Test: build/soong/soong_ui.bash --dumpvars-mode --vars="report_config TARGET_DEVICE" --abs-vars="ALL_PRODUCTS" Test: build/soong/soong_ui.bash --dumpvars-mode --vars=TARGET_DEVICE --abs-vars=PRODUCT_OUT --var-prefix=v_ --abs-var-prefix=a_ Change-Id: I0fbd0732bbf6fcfcd24084cf3c830a91a4b6bfc2
2017-07-14 20:29:29 +02:00
}
varName := flags.Arg(0)
if varName == "report_config" {
varData, err := build.DumpMakeVars(ctx, config, nil, build.BannerVars)
if err != nil {
ctx.Fatal(err)
}
fmt.Println(build.Banner(varData))
} else {
varData, err := build.DumpMakeVars(ctx, config, nil, []string{varName})
if err != nil {
ctx.Fatal(err)
}
if *abs {
var res []string
for _, path := range strings.Fields(varData[varName]) {
if abs, err := filepath.Abs(path); err == nil {
res = append(res, abs)
} else {
ctx.Fatalln("Failed to get absolute path of", path, err)
}
}
fmt.Println(strings.Join(res, " "))
} else {
fmt.Println(varData[varName])
}
}
}
func dumpVars(ctx build.Context, config build.Config, args []string) {
logAndSymlinkSetup(ctx, config)
Add --dumpvar[s]-mode to replace config.mk uses build/soong/soong_ui.bash --dumpvars-mode \ --vars="..." \ --abs-vars="..." \ --var-prefix="..." \ --abs-var-prefix="..." is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dump-many-vars \ DUMP_MANY_VARS="..." \ DUMP_MANY_ABS_VARS="..." \ DUMP_VAR_PREFIX="..." \ DUMP_ABS_VAR_PREFIX="..." and build/soong/soong_ui.bash --dumpvar-mode [--abs] VAR is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dumpvar-[abs-]-VAR But uses soong_ui and ckati, so that we use a consistent make parser and sandboxing configurations. One major output difference between the pure make implementation and this one is that report_config in Go is implemented using embedded newlines in single quotes, while the make implementation uses `` with embedded echo commands. This seems to work fine for both bash and zsh, and report_config isn't meant to be machine-parsed anyways. Test: build/soong/soong_ui.bash --dumpvar-mode report_config Test: build/soong/soong_ui.bash --dumpvar-mode TARGET_DEVICE Test: build/soong/soong_ui.bash --dumpvar-mode --abs PRODUCT_OUT Test: build/soong/soong_ui.bash --dumpvar-mode --abs ALL_PRODUCTS Test: build/soong/soong_ui.bash --dumpvars-mode --vars="report_config TARGET_DEVICE" --abs-vars="ALL_PRODUCTS" Test: build/soong/soong_ui.bash --dumpvars-mode --vars=TARGET_DEVICE --abs-vars=PRODUCT_OUT --var-prefix=v_ --abs-var-prefix=a_ Change-Id: I0fbd0732bbf6fcfcd24084cf3c830a91a4b6bfc2
2017-07-14 20:29:29 +02:00
flags := flag.NewFlagSet("dumpvars", flag.ExitOnError)
flags.SetOutput(ctx.Writer)
Add --dumpvar[s]-mode to replace config.mk uses build/soong/soong_ui.bash --dumpvars-mode \ --vars="..." \ --abs-vars="..." \ --var-prefix="..." \ --abs-var-prefix="..." is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dump-many-vars \ DUMP_MANY_VARS="..." \ DUMP_MANY_ABS_VARS="..." \ DUMP_VAR_PREFIX="..." \ DUMP_ABS_VAR_PREFIX="..." and build/soong/soong_ui.bash --dumpvar-mode [--abs] VAR is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dumpvar-[abs-]-VAR But uses soong_ui and ckati, so that we use a consistent make parser and sandboxing configurations. One major output difference between the pure make implementation and this one is that report_config in Go is implemented using embedded newlines in single quotes, while the make implementation uses `` with embedded echo commands. This seems to work fine for both bash and zsh, and report_config isn't meant to be machine-parsed anyways. Test: build/soong/soong_ui.bash --dumpvar-mode report_config Test: build/soong/soong_ui.bash --dumpvar-mode TARGET_DEVICE Test: build/soong/soong_ui.bash --dumpvar-mode --abs PRODUCT_OUT Test: build/soong/soong_ui.bash --dumpvar-mode --abs ALL_PRODUCTS Test: build/soong/soong_ui.bash --dumpvars-mode --vars="report_config TARGET_DEVICE" --abs-vars="ALL_PRODUCTS" Test: build/soong/soong_ui.bash --dumpvars-mode --vars=TARGET_DEVICE --abs-vars=PRODUCT_OUT --var-prefix=v_ --abs-var-prefix=a_ Change-Id: I0fbd0732bbf6fcfcd24084cf3c830a91a4b6bfc2
2017-07-14 20:29:29 +02:00
flags.Usage = func() {
fmt.Fprintf(ctx.Writer, "usage: %s --dumpvars-mode [--vars=\"VAR VAR ...\"]\n\n", os.Args[0])
fmt.Fprintln(ctx.Writer, "In dumpvars mode, dump the values of one or more legacy make variables, in")
fmt.Fprintln(ctx.Writer, "shell syntax. The resulting output may be sourced directly into a shell to")
fmt.Fprintln(ctx.Writer, "set corresponding shell variables.")
fmt.Fprintln(ctx.Writer, "")
fmt.Fprintln(ctx.Writer, "'report_config' is a special case that dumps a variable containing the")
fmt.Fprintln(ctx.Writer, "human-readable config banner from the beginning of the build.")
fmt.Fprintln(ctx.Writer, "")
Add --dumpvar[s]-mode to replace config.mk uses build/soong/soong_ui.bash --dumpvars-mode \ --vars="..." \ --abs-vars="..." \ --var-prefix="..." \ --abs-var-prefix="..." is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dump-many-vars \ DUMP_MANY_VARS="..." \ DUMP_MANY_ABS_VARS="..." \ DUMP_VAR_PREFIX="..." \ DUMP_ABS_VAR_PREFIX="..." and build/soong/soong_ui.bash --dumpvar-mode [--abs] VAR is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dumpvar-[abs-]-VAR But uses soong_ui and ckati, so that we use a consistent make parser and sandboxing configurations. One major output difference between the pure make implementation and this one is that report_config in Go is implemented using embedded newlines in single quotes, while the make implementation uses `` with embedded echo commands. This seems to work fine for both bash and zsh, and report_config isn't meant to be machine-parsed anyways. Test: build/soong/soong_ui.bash --dumpvar-mode report_config Test: build/soong/soong_ui.bash --dumpvar-mode TARGET_DEVICE Test: build/soong/soong_ui.bash --dumpvar-mode --abs PRODUCT_OUT Test: build/soong/soong_ui.bash --dumpvar-mode --abs ALL_PRODUCTS Test: build/soong/soong_ui.bash --dumpvars-mode --vars="report_config TARGET_DEVICE" --abs-vars="ALL_PRODUCTS" Test: build/soong/soong_ui.bash --dumpvars-mode --vars=TARGET_DEVICE --abs-vars=PRODUCT_OUT --var-prefix=v_ --abs-var-prefix=a_ Change-Id: I0fbd0732bbf6fcfcd24084cf3c830a91a4b6bfc2
2017-07-14 20:29:29 +02:00
flags.PrintDefaults()
}
varsStr := flags.String("vars", "", "Space-separated list of variables to dump")
absVarsStr := flags.String("abs-vars", "", "Space-separated list of variables to dump (using absolute paths)")
varPrefix := flags.String("var-prefix", "", "String to prepend to all variable names when dumping")
absVarPrefix := flags.String("abs-var-prefix", "", "String to prepent to all absolute path variable names when dumping")
flags.Parse(args)
if flags.NArg() != 0 {
flags.Usage()
ctx.Fatalf("Invalid usage")
Add --dumpvar[s]-mode to replace config.mk uses build/soong/soong_ui.bash --dumpvars-mode \ --vars="..." \ --abs-vars="..." \ --var-prefix="..." \ --abs-var-prefix="..." is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dump-many-vars \ DUMP_MANY_VARS="..." \ DUMP_MANY_ABS_VARS="..." \ DUMP_VAR_PREFIX="..." \ DUMP_ABS_VAR_PREFIX="..." and build/soong/soong_ui.bash --dumpvar-mode [--abs] VAR is similar to the previous: CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ make -f build/core/config.mk dumpvar-[abs-]-VAR But uses soong_ui and ckati, so that we use a consistent make parser and sandboxing configurations. One major output difference between the pure make implementation and this one is that report_config in Go is implemented using embedded newlines in single quotes, while the make implementation uses `` with embedded echo commands. This seems to work fine for both bash and zsh, and report_config isn't meant to be machine-parsed anyways. Test: build/soong/soong_ui.bash --dumpvar-mode report_config Test: build/soong/soong_ui.bash --dumpvar-mode TARGET_DEVICE Test: build/soong/soong_ui.bash --dumpvar-mode --abs PRODUCT_OUT Test: build/soong/soong_ui.bash --dumpvar-mode --abs ALL_PRODUCTS Test: build/soong/soong_ui.bash --dumpvars-mode --vars="report_config TARGET_DEVICE" --abs-vars="ALL_PRODUCTS" Test: build/soong/soong_ui.bash --dumpvars-mode --vars=TARGET_DEVICE --abs-vars=PRODUCT_OUT --var-prefix=v_ --abs-var-prefix=a_ Change-Id: I0fbd0732bbf6fcfcd24084cf3c830a91a4b6bfc2
2017-07-14 20:29:29 +02:00
}
vars := strings.Fields(*varsStr)
absVars := strings.Fields(*absVarsStr)
allVars := append([]string{}, vars...)
allVars = append(allVars, absVars...)
if i := indexList("report_config", allVars); i != -1 {
allVars = append(allVars[:i], allVars[i+1:]...)
allVars = append(allVars, build.BannerVars...)
}
if len(allVars) == 0 {
return
}
varData, err := build.DumpMakeVars(ctx, config, nil, allVars)
if err != nil {
ctx.Fatal(err)
}
for _, name := range vars {
if name == "report_config" {
fmt.Printf("%sreport_config='%s'\n", *varPrefix, build.Banner(varData))
} else {
fmt.Printf("%s%s='%s'\n", *varPrefix, name, varData[name])
}
}
for _, name := range absVars {
var res []string
for _, path := range strings.Fields(varData[name]) {
abs, err := filepath.Abs(path)
if err != nil {
ctx.Fatalln("Failed to get absolute path of", path, err)
}
res = append(res, abs)
}
fmt.Printf("%s%s='%s'\n", *absVarPrefix, name, strings.Join(res, " "))
}
Add a Go replacement for our top-level Make wrapper Right now this mostly just copies what Make is doing in build/core/ninja.mk and build/core/soong.mk. The only major feature it adds is a rotating log file with some verbose logging. There is one major functional difference -- you cannot override random Make variables during the Make phase anymore. The environment variable is set, and if Make uses ?= or the equivalent, it can still use those variables. We already made this change for Kati, which also loads all of the same code and actually does the build, so it has been half-removed for a while. The only "UI" this implements is what I'll call "Make Emulation" mode -- it's expected that current command lines will continue working, and we'll explore alternate user interfaces later. We're still using Make as a wrapper, but all it does is call into this single Go program, it won't even load the product configuration. Once this is default, we can start moving individual users over to using this directly (still in Make emulation mode), skipping the Make wrapper. Ideas for the future: * Generating trace files showing time spent in Make/Kati/Soong/Ninja (also importing ninja traces into the same stream). I had this working in a previous version of this patch, but removed it to keep the size down and focus on the current features. * More intelligent SIGALRM handling, once we fully remove the Make wrapper (which hides the SIGALRM) * Reading the experimental binary output stream from Ninja, so that we can always save the verbose log even if we're not printing it out to the console Test: USE_SOONG_UI=true m -j blueprint_tools Change-Id: I884327b9a8ae24499eb6c56f6e1ad26df1cfa4e4
2016-08-22 00:17:17 +02:00
}
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
func stdio() terminal.StdioInterface {
return terminal.StdioImpl{}
}
// dumpvar and dumpvars use stdout to output variable values, so use stderr instead of stdout when
// reporting events to keep stdout clean from noise.
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
func customStdio() terminal.StdioInterface {
return terminal.NewCustomStdio(os.Stdin, os.Stderr, os.Stderr)
}
// dumpVarConfig does not require any arguments to be parsed by the NewConfig.
func dumpVarConfig(ctx build.Context, args ...string) build.Config {
return build.NewConfig(ctx)
}
func buildActionConfig(ctx build.Context, args ...string) build.Config {
flags := flag.NewFlagSet("build-mode", flag.ContinueOnError)
flags.SetOutput(ctx.Writer)
flags.Usage = func() {
fmt.Fprintf(ctx.Writer, "usage: %s --build-mode --dir=<path> <build action> [<build arg 1> <build arg 2> ...]\n\n", os.Args[0])
fmt.Fprintln(ctx.Writer, "In build mode, build the set of modules based on the specified build")
fmt.Fprintln(ctx.Writer, "action. The --dir flag is required to determine what is needed to")
fmt.Fprintln(ctx.Writer, "build in the source tree based on the build action. See below for")
fmt.Fprintln(ctx.Writer, "the list of acceptable build action flags.")
fmt.Fprintln(ctx.Writer, "")
flags.PrintDefaults()
}
buildActionFlags := []struct {
name string
description string
action build.BuildAction
set bool
}{{
name: "all-modules",
description: "Build action: build from the top of the source tree.",
action: build.BUILD_MODULES,
}, {
// This is redirecting to mma build command behaviour. Once it has soaked for a
// while, the build command is deleted from here once it has been removed from the
// envsetup.sh.
name: "modules-in-a-dir-no-deps",
description: "Build action: builds all of the modules in the current directory without their dependencies.",
action: build.BUILD_MODULES_IN_A_DIRECTORY,
}, {
// This is redirecting to mmma build command behaviour. Once it has soaked for a
// while, the build command is deleted from here once it has been removed from the
// envsetup.sh.
name: "modules-in-dirs-no-deps",
description: "Build action: builds all of the modules in the supplied directories without their dependencies.",
action: build.BUILD_MODULES_IN_DIRECTORIES,
}, {
name: "modules-in-a-dir",
description: "Build action: builds all of the modules in the current directory and their dependencies.",
action: build.BUILD_MODULES_IN_A_DIRECTORY,
}, {
name: "modules-in-dirs",
description: "Build action: builds all of the modules in the supplied directories and their dependencies.",
action: build.BUILD_MODULES_IN_DIRECTORIES,
}}
for i, flag := range buildActionFlags {
flags.BoolVar(&buildActionFlags[i].set, flag.name, false, flag.description)
}
dir := flags.String("dir", "", "Directory of the executed build command.")
// Only interested in the first two args which defines the build action and the directory.
// The remaining arguments are passed down to the config.
const numBuildActionFlags = 2
if len(args) < numBuildActionFlags {
flags.Usage()
ctx.Fatalln("Improper build action arguments: too few arguments")
}
parseError := flags.Parse(args[0:numBuildActionFlags])
// The next block of code is to validate that exactly one build action is set and the dir flag
// is specified.
buildActionFound := false
var buildAction build.BuildAction
for _, f := range buildActionFlags {
if f.set {
if buildActionFound {
if parseError == nil {
//otherwise Parse() already called Usage()
flags.Usage()
}
ctx.Fatalf("Build action already specified, omit: --%s\n", f.name)
}
buildActionFound = true
buildAction = f.action
}
}
if !buildActionFound {
if parseError == nil {
//otherwise Parse() already called Usage()
flags.Usage()
}
ctx.Fatalln("Build action not defined.")
}
if *dir == "" {
ctx.Fatalln("-dir not specified.")
}
// Remove the build action flags from the args as they are not recognized by the config.
args = args[numBuildActionFlags:]
return build.NewBuildActionConfig(buildAction, *dir, ctx, args...)
}
func runMake(ctx build.Context, config build.Config, _ []string) {
logAndSymlinkSetup(ctx, config)
logsDir := config.LogsDir()
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
if config.IsVerbose() {
writer := ctx.Writer
fmt.Fprintln(writer, "! The argument `showcommands` is no longer supported.")
fmt.Fprintln(writer, "! Instead, the verbose log is always written to a compressed file in the output dir:")
fmt.Fprintln(writer, "!")
fmt.Fprintf(writer, "! gzip -cd %s/verbose.log.gz | less -R\n", logsDir)
fmt.Fprintln(writer, "!")
fmt.Fprintln(writer, "! Older versions are saved in verbose.log.#.gz files")
fmt.Fprintln(writer, "")
ctx.Fatal("Invalid argument")
}
if _, ok := config.Environment().Get("ONE_SHOT_MAKEFILE"); ok {
writer := ctx.Writer
fmt.Fprintln(writer, "! The variable `ONE_SHOT_MAKEFILE` is obsolete.")
fmt.Fprintln(writer, "!")
fmt.Fprintln(writer, "! If you're using `mm`, you'll need to run `source build/envsetup.sh` to update.")
fmt.Fprintln(writer, "!")
fmt.Fprintln(writer, "! Otherwise, either specify a module name with m, or use mma / MODULES-IN-...")
fmt.Fprintln(writer, "")
ctx.Fatal("Invalid environment")
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
}
build.Build(ctx, config)
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
}
// getCommand finds the appropriate command based on args[1] flag. args[0]
// is the soong_ui filename.
func getCommand(args []string) (*command, []string, error) {
listFlags := func() []string {
flags := make([]string, len(commands))
for i, c := range commands {
flags[i] = c.flag
}
return flags
}
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
if len(args) < 2 {
return nil, nil, fmt.Errorf("Too few arguments: %q\nUse one of these: %q", args, listFlags())
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
}
for _, c := range commands {
if c.flag == args[1] {
return &c, args[2:], nil
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
}
}
return nil, nil, fmt.Errorf("Command not found: %q\nDid you mean one of these: %q", args[1], listFlags())
Soong: Refactor the soong_ui arguments processing to be more like bazel. Currently, the command line argments is being processed in multiple places. In the main soong_ui arguments, there are several if statements that checks if a specific argument was specified in order to execute the requested operation. This does not scale well when adding or removing a command in the near future. In order to support the build commands (m, mma, etc...) from the envsetup.sh in soong_ui, a refactor was required in order to add a command rather quickly and to have the flexibiity to unit test the command. The soong_ui arguments format is as follows: soong_ui <command> [<arg 1> <arg 2> ... <arg n>] The <command> is a specific operation to be executed. The arguments after the command are processed by the command itself. Below is the list of changes made in this commit: * Created a new command infrastructure that allows adding or deprecating a command easily. * Fixed a bug when running ./soong_ui.bash directly would cause a panic due to index being out of range for args list. Bug: b/130049705 Test: Below is the list of testing done on this commit: * Ran lunch and verified that the output is the same as the the output without the modifications. lunch indirectly runs soong_ui passing in the --dumpvar-mode (to read makefile variables such as TARGET_PRODUCT) and --dumpvars-mode (to build the build cache). * Ran ./soong_ui.bash directly (with unsupported flags and no flags) and the proper message appeared that soong native UI is not yet available. * Ran m, mm, mmm, mma, mmma commands. * Ran the make installclean command: make -j80 TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=eng dist DIST_DIR=/tmp/helloworld installclean * Ran ./out/soong_ui -j80 --make-mode PRODUCT-aosp_arm64-eng dist checkbuild tests Change-Id: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22 Merged-In: Iee4de7ec0fa4661206fda8ae1fe6fa4487d9bb22
2019-04-10 03:49:49 +02:00
}
// For Bazel support, this moves files and directories from e.g. out/dist/$f to DIST_DIR/$f if necessary.
func populateExternalDistDir(ctx build.Context, config build.Config) {
// Make sure that internalDistDirPath and externalDistDirPath are both absolute paths, so we can compare them
var err error
var internalDistDirPath string
var externalDistDirPath string
if internalDistDirPath, err = filepath.Abs(config.DistDir()); err != nil {
ctx.Fatalf("Unable to find absolute path of %s: %s", internalDistDirPath, err)
}
if externalDistDirPath, err = filepath.Abs(config.RealDistDir()); err != nil {
ctx.Fatalf("Unable to find absolute path of %s: %s", externalDistDirPath, err)
}
if externalDistDirPath == internalDistDirPath {
return
}
// Make sure the internal DIST_DIR actually exists before trying to read from it
if _, err = os.Stat(internalDistDirPath); os.IsNotExist(err) {
ctx.Println("Skipping Bazel dist dir migration - nothing to do!")
return
}
// Make sure the external DIST_DIR actually exists before trying to write to it
if err = os.MkdirAll(externalDistDirPath, 0755); err != nil {
ctx.Fatalf("Unable to make directory %s: %s", externalDistDirPath, err)
}
ctx.Println("Populating external DIST_DIR...")
populateExternalDistDirHelper(ctx, config, internalDistDirPath, externalDistDirPath)
}
func populateExternalDistDirHelper(ctx build.Context, config build.Config, internalDistDirPath string, externalDistDirPath string) {
files, err := ioutil.ReadDir(internalDistDirPath)
if err != nil {
ctx.Fatalf("Can't read internal distdir %s: %s", internalDistDirPath, err)
}
for _, f := range files {
internalFilePath := filepath.Join(internalDistDirPath, f.Name())
externalFilePath := filepath.Join(externalDistDirPath, f.Name())
if f.IsDir() {
// Moving a directory - check if there is an existing directory to merge with
externalLstat, err := os.Lstat(externalFilePath)
if err != nil {
if !os.IsNotExist(err) {
ctx.Fatalf("Can't lstat external %s: %s", externalDistDirPath, err)
}
// Otherwise, if the error was os.IsNotExist, that's fine and we fall through to the rename at the bottom
} else {
if externalLstat.IsDir() {
// Existing dir - try to merge the directories?
populateExternalDistDirHelper(ctx, config, internalFilePath, externalFilePath)
continue
} else {
// Existing file being replaced with a directory. Delete the existing file...
if err := os.RemoveAll(externalFilePath); err != nil {
ctx.Fatalf("Unable to remove existing %s: %s", externalFilePath, err)
}
}
}
} else {
// Moving a file (not a dir) - delete any existing file or directory
if err := os.RemoveAll(externalFilePath); err != nil {
ctx.Fatalf("Unable to remove existing %s: %s", externalFilePath, err)
}
}
// The actual move - do a rename instead of a copy in order to save disk space.
if err := os.Rename(internalFilePath, externalFilePath); err != nil {
ctx.Fatalf("Unable to rename %s -> %s due to error %s", internalFilePath, externalFilePath, err)
}
}
}
func setMaxFiles(ctx build.Context) {
var limits syscall.Rlimit
err := syscall.Getrlimit(syscall.RLIMIT_NOFILE, &limits)
if err != nil {
ctx.Println("Failed to get file limit:", err)
return
}
ctx.Verbosef("Current file limits: %d soft, %d hard", limits.Cur, limits.Max)
if limits.Cur == limits.Max {
return
}
limits.Cur = limits.Max
err = syscall.Setrlimit(syscall.RLIMIT_NOFILE, &limits)
if err != nil {
ctx.Println("Failed to increase file limit:", err)
}
}
func finalizeBazelMetrics(ctx build.Context, config build.Config, args []string) {
updateTotalRealTime(ctx, config, args)
logsDir := config.LogsDir()
logsPrefix := config.GetLogsPrefix()
bazelMetricsFile := filepath.Join(logsDir, logsPrefix+"bazel_metrics.pb")
bazelProfileFile := filepath.Join(logsDir, logsPrefix+"analyzed_bazel_profile.txt")
build.ProcessBazelMetrics(bazelProfileFile, bazelMetricsFile, ctx, config)
}
func updateTotalRealTime(ctx build.Context, config build.Config, args []string) {
soongMetricsFile := filepath.Join(config.LogsDir(), "soong_metrics")
//read file into proto
data, err := os.ReadFile(soongMetricsFile)
if err != nil {
ctx.Fatal(err)
}
met := ctx.ContextImpl.Metrics
err = met.UpdateTotalRealTimeAndNonZeroExit(data, config.BazelExitCode())
if err != nil {
ctx.Fatal(err)
}
}