diff options
author | Han-Wen Nienhuys <hanwen@google.com> | 2016-01-28 12:35:13 +0000 |
---|---|---|
committer | Kristina Chodorow <kchodorow@google.com> | 2016-01-28 15:30:33 +0000 |
commit | de435f4bd1a46f2a0f28d42f302f0eb05517ca9c (patch) | |
tree | 666594b618237c1fd6cce3fe81bc60243e5f0f3d /site | |
parent | c63b90f8828cf5c5c17d028d2e1a41371bf11c24 (diff) |
Rename native.rule and native.rules to {existing_rule,existing_rules}
This is to avoid confusion between rule(), which declares a new build
rules, and native.rule(), which can only be used in macros to inspect
the BUILD file processed so far.
native.{rule,rules} is maintained and marked deprecated to smooth the
transition for early adopters.
--
MOS_MIGRATED_REVID=113250194
Diffstat (limited to 'site')
-rw-r--r-- | site/docs/skylark/cookbook.md | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/site/docs/skylark/cookbook.md b/site/docs/skylark/cookbook.md index 60f441fc71..bf96adc55f 100644 --- a/site/docs/skylark/cookbook.md +++ b/site/docs/skylark/cookbook.md @@ -66,11 +66,11 @@ macro(name = "myrule") ## <a name="conditional-instantiation"></a>Conditional instantiation. Macros can look at previously instantiated rules. This is done with -`native.rule`, which returns information on a single rule defined in the same +`native.existing_rule`, which returns information on a single rule defined in the same `BUILD` file, eg., ```python -native.rule("descriptor_proto") +native.existing_rule("descriptor_proto") ``` This is useful to avoid instantiating the same rule twice, which is an @@ -82,7 +82,7 @@ tests for diverse flavors of the same test. ```python def system_test(test_file, flavor): n = "system_test_%s_%s_test" % (test_file, flavor) - if native.rule(n) == None: + if native.existing_rule(n) == None: native.py_test( name = n, srcs = [ "test_driver.py", test_file ], @@ -115,22 +115,22 @@ system_test_suite("thorough", flavors=["fast", "debug", "opt"], ["basic_test.py" Macros can collect information from the BUILD file as processed so far. We call this aggregation. The typical example is collecting data from all rules of a -certain kind. This is done by calling `native.rules`, which returns a +certain kind. This is done by calling `native.existing_rules`, which returns a dictionary representing all rules defined so far in the current BUILD file. The dictionary has entries of the form `name` => `rule`, with the values using the -same format as `native.rule`. +same format as `native.existing_rule`. ```python def archive_cc_src_files(tag): """Create an archive of all C++ sources that have the given tag.""" all_src = [] - for r in native.rules().values(): + for r in native.existing_rules().values(): if tag in r["tags"] and r["kind"] == "cc_library": all_src.append(r["srcs"]) native.genrule(cmd = "zip $@ $^", srcs = all_src, outs = ["out.zip"]) ``` -Since `native.rules` constructs a potentially large dictionary, you should avoid +Since `native.existing_rules` constructs a potentially large dictionary, you should avoid calling it repeatedly within BUILD file. ## <a name="empty"></a>Empty rule |