| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
| |
Before this cl the sysroot variable was not present, and that's a bug.
RELNOTES: None
PiperOrigin-RevId: 203346557
|
|
|
|
| |
PiperOrigin-RevId: 203230801
|
|
|
|
|
|
|
|
| |
producing add_dep commands where possible and avoids the need for direct dependencies on supertypes of directly depended types
RELNOTES: None.
PiperOrigin-RevId: 203164113
|
|
|
|
|
|
| |
pre-https://github.com/bazelbuild/bazel/commit/4a2002043ed3907223a403e8b8fc66975e516fd8 behaviour for non-strict proto classpaths
PiperOrigin-RevId: 203126457
|
|
|
|
|
|
|
| |
Also remove batch in these same tests in favor of the new --nokeep_state_after_build
RELNOTES: None.
PiperOrigin-RevId: 203011055
|
|
|
|
|
|
|
|
|
|
| |
Add a new standard feature set to the Xcode version being used for
compilation. (The feature is named `xcode_VERSION`, where `VERSION` is
at least a two-component version number; `xcode_9.0` and `xcode_9.2` are
both possible values.) This provides CROSSTOOL authors a mechanism to
deploy compiler flags supported only in certain Xcode versions.
PiperOrigin-RevId: 203000420
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 202943806
|
|
|
|
|
|
|
|
|
| |
that depend on BUILD/CROSSTOOL files.
Also add @Deprecated tags for these methods and extract CppConfigurationSkylarkTest in a separate class so that it actually gets run (followup change with the explanation a-coming)
RELNOTES: None.
PiperOrigin-RevId: 202903559
|
|
|
|
|
|
|
|
|
| |
implement it.
Also clarify the behavior of the expand_template API in the presence of multiple-substitutions.
RELNOTES: None
PiperOrigin-RevId: 202719656
|
|
|
|
| |
PiperOrigin-RevId: 202704472
|
|
|
|
| |
PiperOrigin-RevId: 202703621
|
|
|
|
|
|
|
|
|
|
| |
This is done so that we can check whether the current target can use the C++
Skylark API.
Rolling forward: BlazeInvocationPolicy is not used in host configuration. We simply ignore host configuration and not give an error when we are building there.
RELNOTES:none
PiperOrigin-RevId: 202652552
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[Rolling forward https://github.com/bazelbuild/bazel/commit/c4e128e2c6d8cacaeba034d6a3195796d50f1745]
java_common.compile doesn't generate the output source jar when a source jar is
the only input for the compilation. This is wrong because the source jar can
include APT generated sources. It is also inconsistent with java_library and
leads to inconsistent Skylark rules where a declared output will not always have a
generating action.
This new behavior is guarded by a new flag --incompatible_generate_javacommon_source_jar.
RELNOTES: None.
PiperOrigin-RevId: 202648346
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks tests: b/110978519
*** Original change description ***
C++: Adds ctx to cc_link_params creation.
This is done so that we can check whether the current target can use the C++
Skylark API.
RELNOTES:none
PiperOrigin-RevId: 202643988
|
|
|
|
|
|
|
|
| |
This is done so that we can check whether the current target can use the C++
Skylark API.
RELNOTES:none
PiperOrigin-RevId: 202632582
|
|
|
|
|
|
| |
and avoid needlessly copying lists.
PiperOrigin-RevId: 202504396
|
|
|
|
|
| |
RELNOTES:none:
PiperOrigin-RevId: 202491609
|
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 202483718
|
|
|
|
|
|
|
| |
Closes #5478.
Change-Id: I3ac44605ef16a7c2e6bdc63d26fdf968bef651aa
PiperOrigin-RevId: 202482493
|
|
|
|
|
|
|
|
| |
Make ObjcRuleClasses uses CppRuleClasses.ccToolchainAttribute label resolver.
Mark CppRuleClasses.ccToolchainAttribute with @AutoCodec annotation.
RELNOTES:none
PiperOrigin-RevId: 202479836
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an implementation of the design at
https://docs.google.com/document/d/1g91BWJITcYw_X-VxsDC0VgUn5E9g0kRBGoBSpoO41gA/edit>.
More thorough documentation will be sent in a separate cl. The api was approved
at
https://docs.google.com/document/d/1M8JA7kzZnWpLZ3WEX9rp6k2u_nlwE8smsHYgVTSSJ9k/edit?ts=5b292400#.
Work towards #4571 (only the docs are missing).
RELNOTES: None.
PiperOrigin-RevId: 202464331
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 202386363
|
|
|
|
|
|
| |
FeatureConfiguration.
PiperOrigin-RevId: 202363333
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 202360925
|
|
|
|
|
|
|
|
|
| |
The Skylark constructor of CcCompilationInfo now accepts headers. This may be
the last piece needed to get a working prototype of foreign C++ libraries. Next
step would be open sourcing the sandwich.
RELNOTES:none
PiperOrigin-RevId: 202306252
|
|
|
|
|
|
|
|
|
| |
Consolidate the creation of JavaCompilationArgsProviders, and avoid explicit
handling of the 'direct' and 'recursive' cases in clients. Also add some
higher-level methods to the builder API to support adding dependencies
with dep/export/runtime_dep-like semantics.
PiperOrigin-RevId: 202166383
|
|
|
|
|
|
|
|
|
| |
CppCompileAction.discoverInputsStage2 retrieves values of discovered modules
from ActionExecutionValue.
This addresses a possible a correctness issue.
PiperOrigin-RevId: 202162180
|
|
|
|
|
|
|
| |
This was never used. We thought it will be useful, but it's not.
RELNOTES: None.
PiperOrigin-RevId: 202143524
|
|
|
|
|
|
|
| |
Makes it non-instantiable so that it's easier to migrate SWIG rules to Skylark.
RELNOTES:none
PiperOrigin-RevId: 202136054
|
|
|
|
|
|
|
| |
they are used on the phone.
RELNOTES: None.
PiperOrigin-RevId: 202117007
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, Bazel expected that it can compile whatever appeared in cc_library.srcs
directory artifacts. That is true for C/C++ source files, and for headers when
the C++ toolchain supported header parsing/processing (which used
CppCompileAction). When the toolchain doesn't support header parsing/processing,
Bazel would crash.
Addresses issue #5092. One part of it.
Fixes #5372.
RELNOTES: None.
PiperOrigin-RevId: 202114286
|
|
|
|
|
|
|
|
|
| |
To get a CcCompilationInfo instance from Skylark it will either have to be
through its constructor (not yet fully implemented) which will not schedule any
actions or through a call to compile() which does schedule actions.
RELNOTES:none
PiperOrigin-RevId: 202099841
|
|
|
|
| |
PiperOrigin-RevId: 201969238
|
|
|
|
|
|
|
|
|
|
| |
I will remove the CcLinkParamsStore class in a separate CL. For now, make sure
the API doesn't expose this class.
The only Skylark use was in cc_import which is migrated in this CL.
RELNOTES:none
PiperOrigin-RevId: 201948058
|
|
|
|
|
| |
Change-Id: I355b138e143771fd826ab03951df821ea7d58ac5
PiperOrigin-RevId: 201740564
|
|
|
|
| |
PiperOrigin-RevId: 201723154
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
see b/109887056
*** Original change description ***
Stop objc_proto_library from returning the generated sources.
PiperOrigin-RevId: 201709908
|
|
|
|
|
|
|
|
|
|
|
| |
Like with providers, consumers get a merged view of all actions from the merged configured target (all other aspects + the base target).
I had to rejig the aspect value / configured aspect to be symmetric with rule configured targets.
I do not expect significant memory bloat from this. All lists / maps already existed, only extra fields have been added.
RELNOTES: Expose aspect actions provider to Skylark.
PiperOrigin-RevId: 201697923
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 201617188
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only non-deprecated way to declare new files in Skylark is using ctx.actions
(https://docs.bazel.build/versions/master/skylark/lib/actions.html). And these
files are created in binfiles (there is one way to generate a file in Skylark in
genfiles: a rule can be tagget with 'output_to_genfiles = True'
attribute, but that forces all files of all actions in the rule to be generated
in genfiles. And this attribtue is deprecated).
Similarly, https://github.com/bazelbuild/bazel/commit/6c2f499b21e36c59d7da5e8b2e6c9b1804a36c64 added binfiles for <> includes when using
cc_library.includes attribute.
RELNOTES: None.
PiperOrigin-RevId: 201504199
|
|
|
|
|
|
|
|
|
| |
CrosstoolInfo carries the necessary information from the CROSSTOOL text proto. Later on, instead from the CROSSTOOL file and the corresponding CToolchain, CrosstoolInfo will be derived from a skylark_crosstool rule implemented in Skylark. Therefore CToolchain involvement in CppConfiguration and CcToolchain creation needs to be eliminated.
Work towards issue #5380
RELNOTES: None.
PiperOrigin-RevId: 201491207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This corresponds to the os version in the clang target triple, though clang
does have corresponding os_version_min flags for Apple platforms.
Currently, Bazel has --XX_minimum_os flags for XX values corresponding to Apple
platforms.
This flag is the generic version of that (and can and will be set after the
Apple split transition, and will eventually be set in the Android split as
well) to support various Android API level improvements for native code.
PiperOrigin-RevId: 201453961
|
|
|
|
|
|
|
|
|
|
|
|
| |
The corresponding flags have been flipped and there should be no code in the depot that violates these rules.
* Make it completely illegal for proto_library to appear in any Java/Android rule
* Delete code that uses the old migration flags.
* Delete tests that check that Java/Android rules *can* depend on proto_library rules when certain flags are off.
* Update tests (the error messages are now slightly different)
RELNOTES: None
PiperOrigin-RevId: 201384236
|
|
|
|
|
| |
RELNOTES=None
PiperOrigin-RevId: 201365986
|
|
|
|
|
|
| |
The general handling should be fine for this.
PiperOrigin-RevId: 201352916
|
|
|
|
|
|
|
| |
I will put cc_import.bzl in Bazel in a follow up CL.
RELNOTES:none
PiperOrigin-RevId: 201332133
|
|
|
|
|
|
| |
RELNOTES[INC]: The $(JAVA_TRANSLATIONS) Make variable is not supported anymore.
PiperOrigin-RevId: 201278971
|
|
|
|
| |
PiperOrigin-RevId: 201228699
|
|
|
|
|
|
| |
Get rid of a useless tag, because the Function being tagged is a concrete class, so won't be serializable. Will deal with it in a follow-up. Implement equality for BazelInfo.
PiperOrigin-RevId: 201199255
|