Bug: 190051051
Test: treehugger
Change-Id: Ib77d8af8f926412f6337173927cee6bb1deda2bb

Test: not required - documentation change

Change-Id: Ib487278e7ca183fd968df70fb701a8cdf7266c19

Each variable can specify a conditions_default for properties to be used
when the variable is not set, not set to a true value (for bools), or is
set to a value that is not present in the module (for strings).

Test: m nothing
Test: go test soong tests
Change-Id: I76ec026da2369b407f0f530f77760f530e7958fc

Visibility rules can be 'inherited' in one of two ways. Either from
defaults or from a module that called ctx.CreateModule(...).
Previously, in both cases the inheriting module could only append
additional visibility rules to the end of the inherited rules. That
made it impossible to restrict the visibility by removing or ignore
inherited rules.

The //visibility:override rectifies that by allowing the inheriting
module to ignore all the rules that they would have inherited. It can
only go at the beginning of a list of rules specified in a module but
after defaults are applied it can end up in the middle of a list of
rules. In that case it behaves as if all the rules up to and including
the //visibility:override rule were discarded.

It can be used with //visibility:private to override
//visibility:public and vice versa.

Bug: 155787200
Test: m nothing
Merged-In: I8a9c9c5a1bdceaee387c08864ae2b34629e0d46f
Change-Id: I8a9c9c5a1bdceaee387c08864ae2b34629e0d46f
(cherry picked from commit 51084ff6)

Visibility rules can be 'inherited' in one of two ways. Either from
defaults or from a module that called ctx.CreateModule(...).
Previously, in both cases the inheriting module could only append
additional visibility rules to the end of the inherited rules. That
made it impossible to restrict the visibility by removing or ignore
inherited rules.

The //visibility:override rectifies that by allowing the inheriting
module to ignore all the rules that they would have inherited. It can
only go at the beginning of a list of rules specified in a module but
after defaults are applied it can end up in the middle of a list of
rules. In that case it behaves as if all the rules up to and including
the //visibility:override rule were discarded.

It can be used with //visibility:private to override
//visibility:public and vice versa.

Bug: 155787200
Test: m nothing
Change-Id: I8a9c9c5a1bdceaee387c08864ae2b34629e0d46f

There are some cases that aren't handled with the existing variable
types for booleans or known lists of strings. Similarly to our
product_variables that uses %s / %d for things like
PLATFORM_SDK_VERSION, allow vendors to define their own config variables
to be substituted into properties.

For example, some of the makefiles that I've attempted to convert had
the option to pass in version numbers from the board, or the default
display size:

  -DDISPLAY_VERSION=550
  -DDISP_H=1080

These examples happen to be integers, but since our configuration
language (make) doesn't support numbers, %s works just as well.

This change will allow the above to be represented using:

  soong_config_module_type {
      name: "acme_cc_defaults",
      module_type: "cc_defaults",
      config_namespace: "acme",
      value_variables: [
          "DISPLAY_VERSION",
	  "DISP_H",
      ],
      properties: ["cflags"],
  }

  acme_cc_defaults {
      name: "my_defaults",
      soong_config_variables: {
          DISPLAY_VERSION: {
	      cflags: ["-DDISPLAY_VERSION=%s"],
	  },
	  DISP_H: {
	      cflags: ["-DDISP_H=%s"],
	  }
      },
  }

Bug: 153161144
Test: built-in tests
Change-Id: I18f35746b5cc39c304a136980249e886d38c6df6
Merged-In: I18f35746b5cc39c304a136980249e886d38c6df6
(cherry picked from commit b0935db8)

Using a lot of boolean variables can become very verbose without adding
really any new information:

      variables: ["a", "b", "c"],
  }

  soong_config_bool_variable {
      name: "a",
  }

  soong_config_bool_variable {
      name: "b",
  }

  soong_config_bool_variable {
      name: "c",
  }

Now turns into:

      bool_variables: ["a", "b", "c"],
  }

Bug: 153161144
Test: built-in tests
Change-Id: If5455a38433431c7ecbce1e5b32cfbb47f42602a
Merged-In: If5455a38433431c7ecbce1e5b32cfbb47f42602a
(cherry picked from commit 2b8b89cf)

There are some cases that aren't handled with the existing variable
types for booleans or known lists of strings. Similarly to our
product_variables that uses %s / %d for things like
PLATFORM_SDK_VERSION, allow vendors to define their own config variables
to be substituted into properties.

For example, some of the makefiles that I've attempted to convert had
the option to pass in version numbers from the board, or the default
display size:

  -DDISPLAY_VERSION=550
  -DDISP_H=1080

These examples happen to be integers, but since our configuration
language (make) doesn't support numbers, %s works just as well.

This change will allow the above to be represented using:

  soong_config_module_type {
      name: "acme_cc_defaults",
      module_type: "cc_defaults",
      config_namespace: "acme",
      value_variables: [
          "DISPLAY_VERSION",
	  "DISP_H",
      ],
      properties: ["cflags"],
  }

  acme_cc_defaults {
      name: "my_defaults",
      soong_config_variables: {
          DISPLAY_VERSION: {
	      cflags: ["-DDISPLAY_VERSION=%s"],
	  },
	  DISP_H: {
	      cflags: ["-DDISP_H=%s"],
	  }
      },
  }

Test: built-in tests
Change-Id: I18f35746b5cc39c304a136980249e886d38c6df6

Using a lot of boolean variables can become very verbose without adding
really any new information:

      variables: ["a", "b", "c"],
  }

  soong_config_bool_variable {
      name: "a",
  }

  soong_config_bool_variable {
      name: "b",
  }

  soong_config_bool_variable {
      name: "c",
  }

Now turns into:

      bool_variables: ["a", "b", "c"],
  }

Test: built-in tests
Change-Id: If5455a38433431c7ecbce1e5b32cfbb47f42602a

Support vendor conditionals with no Go code.

Test: TestSoongConfigModule
Change-Id: I42546e7f17324921ada80f4d8e1cd399830f8dfc

Test: N/A
Change-Id: Iec7d40e6886285046fbe00aea8e19073c6c1ba73

Taken from the comment for OutputFileProducer in android/module.go.

Test: n/a
Change-Id: If74e9072333ed2acd51e1019d5e756cf54c9e55e

Test: none
Change-Id: I5ccf5824c6a85d881070d8e0ae16d87d3ee6cee2

Fixes: 138580915
Test: m checkbuild
Change-Id: Iefee8a914225d465a1feb37690a54423be332841

Bug: 130796911
Test: m nothing
Change-Id: I7b9462d3360be2bbeaf6ff38c5328f45ff5b5ebb

Allow running Soong in a headless delve debugger by passing
SOONG_DELVE=<listen addr> in the environment.

Bug: 80165685
Test: SOONG_DELVE=:1234 m nothing
Change-Id: Icfc893c8a8354a9bbc99112d9c83259cb41906d1

Enhances the visibility mechanism to use the default_visibility
property of the closest ancestor package that has the property
specified.

Bug: 133290645
Test: m droid
Change-Id: I7248e9034a73894ac8d514f913316438c4d7c079

Adds a package module type with a default_visibility property. The
package module type can only be specified once per package.

Bug: 133290645
Test: m droid
Change-Id: Ibb2fb499c9ea88ecaa662d3cd2cbde478e4b9a4b

Document that strings can contain double quotes escaped as \", and
the droiddoc args argument can contain a dollar signe escaped as $$.

Test: none
Change-Id: I91d3fa73f484094c9ce8cbecc93189850856de84

However only allow it when they are merged from different defaults.

Extend the tests to cover that and other cases with visibilities in
defaults.

Also avoid dumping the whole visibility spec in the error message when a
visibility check fails, because it gets noisy for long visibility lists, and
can be confusing when //visibility:public gets merged with other visibility
rules.

Test: Soong self test
Bug: 112158820
Bug: 130796911
Change-Id: I242513975a3f824b9ea2eab5b94b194b9af2481b

Implementation uploaded for review. Includes unit tests but does not
yet handle prebuilts, that will come in a future change once some
more general issues with prebuilts and namespaces is resolved.

See README.md#Visibility for details of what this does and how to use
it.

Bug: 112158820
Test: add visibility rules for core library modules, make core-tests
Change-Id: I8ec980554398ad6f2d42043ce518f811a35da679

The built reference documentation is now hosted publicly.

Test: check the link in gitiles
Change-Id: I69c90f2d74f1e7535054aed115930a293057ad48

On the recent versions, the module types help
is generated into $OUT_DIR/soong/docs/soong_build.html

Test: make && ls -l out/soong/docs/soong_build.html
Change-Id: Ib7522a417fd5467f19d7393672a592d349f276f4

Test: make online-sac-docs

Bug: 120866204
Change-Id: I4560a32ec2cb29aaaa9e9048d4ed075d09a44d13

Change-Id: Ia14b1a5b1f96c3a70465eb1c34367deb5c1d4234

Test: none
Change-Id: I507b7118bfc240166dced0cc26ab523ce56f68a2

Bug: 71906438
Test: none
Change-Id: Ic18f2dc5d91b30ff2b5beb8047d98591ba70ee00

Some tools (i.e. you-complete-me) make use of a 'compdb' file
(compile_commands.json) that records (among other things) the
arguments needed to compile a file. These tools can use this with
libclang to provide semantic completions and perform other IDE
actions. This CL adds support for soong to generate a (simple)
compile_commands.json file.

Test: make SOONG_GEN_COMPDB=1 SOONG_LINK_COMPDB_TO=$ANDROID_BUILD_TOP nothing
      examine $ANDROID_BUILD_TOP/compile_commands.json

Change-Id: I751bb344b90dfcdad1dfd71c2a85bacd345f0464

Test: check gitiles view
Change-Id: I2fa4fa5f7ee91ba586e1900542c8c334eb727a6b

Bug: 65683273
Test: Read README.md

Change-Id: I179c085e123858ae425515ac6bbf4b272c245a2e

Test: m clean && m -j java and java_test.go

Change-Id: I110a0ff029448d3319aed2788d25d90a6c1a7fa0

Test: None
Change-Id: Ie2ad921974dc4ff82a3c6308736830cacfebf806

filegroup is a module that contains a list of files, and can be used
to export files across package boundaries.  filegroups (and genrules)
can be referenced from srcs properties of other modules using the
syntax ":module".

Test: m -j
Change-Id: I3d6fc4819c0b4225b474e0ad42f0d947f55a5961

Use go/Android.bp link, add a little more on androidmk conversions.

Test: none
Change-Id: Ibe2be4ad54b6d9a8954d7efbb40d04dc54c8dbf2

Change-Id: I07970cddefb981f6708b276ac5b04d311d1843d9