| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
targets to upstream cc_library targets.
PiperOrigin-RevId: 194816009
|
|
|
|
|
|
|
| |
CcLinkingInfo will eventually wrap all C++ linking providers. CcLinkParamsInfo is no longer a provider and will be renamed in a later CL.
RELNOTES:none
PiperOrigin-RevId: 193011702
|
|
|
|
|
|
| |
Errors are related to missing headers from C++ dependencies.
PiperOrigin-RevId: 192132907
|
|
|
|
|
|
|
| |
For now, only CcCompilationContextInfo is wrapped. CcCompilationContextInfo will be renamed CcCompilationContext since the *Info suffix is used for providers. This will be done in a follow-up CL.
RELNOTES:none
PiperOrigin-RevId: 191876504
|
|
|
|
|
|
| |
J2Objc needs special consideration to implement strict Swift-ObjC deps. The module maps for the generated Objective-C code are associated with their originating java_library targets (via the J2Objc aspect), which a swift_library cannot directly depend on. So those deeper down module maps need to be propagated transitively *until* a j2objc_library is reached; at that point, the j2objc_library should propagate all of its Java deps module maps, but *not* any of its j2objc_library deps (because that would be non-strict).
PiperOrigin-RevId: 191754811
|
|
|
|
|
|
|
|
|
| |
This is done so that the name CcCompilationInfo can be used for the C++
provider that will wrap all providers for compilation, similar to JavaInfo in
Java.
RELNOTES:none
PiperOrigin-RevId: 191445120
|
|
|
|
|
|
|
|
|
| |
--incompatible_disable_objc_provider_resources is true.
This involves propagating SkylarkSemantics to all ObjcProvider constructors.
RELNOTES: Introduce --incompatible_disable_objc_provider_resources to turn off all resource-related fields of the Objc provider.
PiperOrigin-RevId: 190778491
|
|
|
|
|
|
| |
ConfiguredTargetAndData. We want to get BuildConfiguration out of ConfiguredTarget because it uses >800K when serialized.
PiperOrigin-RevId: 188600002
|
|
|
|
|
|
| |
This flag changes the behavior of objc_library module map propagation so that module maps are only propagated to direct dependents, not transitive dependents. swift_library targets that import Objective-C code must then list those dependencies directly in its deps instead of depending on them being transitively present.
PiperOrigin-RevId: 187184692
|
|
|
|
|
|
|
|
| |
The old TransitiveInfoProvider is deprecated. Providers used from Skylark
should use NativeInfo as specified in[]
RELNOTES:none
PiperOrigin-RevId: 186447814
|
|
|
|
|
|
|
| |
This is in preparation for migrating to the new way of specifying providers as described in[]
RELNOTES:none
PiperOrigin-RevId: 186436462
|
|
|
|
|
|
|
|
| |
to ConfiguredTarget.GetTarget(). Also remove equivalence requirements for
the ConfiguredTarget's target and the stored Target since there will soon no
longer be a Target in ConfiguredTarget.
PiperOrigin-RevId: 185417468
|
|
|
|
|
|
|
|
| |
objc_library that it depends on.
See https://github.com/bazelbuild/bazel/issues/3352
PiperOrigin-RevId: 185371993
|
|
|
|
|
|
| |
path class.
PiperOrigin-RevId: 182526427
|
|
|
|
|
|
|
|
|
| |
Infer those values from STATIC_FRAMEWORK_FILE.
This correctly dedupes static frameworks between an app and its dylibs.
RELNOTES: None.
PiperOrigin-RevId: 177214770
|
|
|
|
|
|
|
|
| |
Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own.
This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually.
PiperOrigin-RevId: 175033526
|
|
|
|
|
|
| |
Progress on #2475.
PiperOrigin-RevId: 170473111
|
|
|
|
|
|
| |
This is a trivial change with a large file footprint.
PiperOrigin-RevId: 169169864
|
|
|
|
| |
PiperOrigin-RevId: 167154793
|
|
|
|
|
|
| |
that is accessible to the c++ rules.
PiperOrigin-RevId: 166934390
|
|
|
|
|
|
|
| |
it turns out these keys are still used by objc_framework, so cannot be removed.
RELNOTES: None.
PiperOrigin-RevId: 166895085
|
|
|
|
|
|
| |
closure.
PiperOrigin-RevId: 165934905
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 165910455
|
|
|
|
|
| |
RELNOTES: Removing a few unused objc_provider keys.
PiperOrigin-RevId: 165230824
|
|
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/21436e062a12b64c8bee665b0cf79dfe48cff114.
That change broke module maps that depended on the transitive headers from ObjC protos.
RELNOTES: None
PiperOrigin-RevId: 165010275
|
|
|
|
| |
PiperOrigin-RevId: 164590595
|
|
|
|
|
|
|
|
| |
Follows
https://docs.google.com/document/d/1aAIVWvHPERDz2cv_PCFGwr8dvh5FcAkENFoRsNS4clk/.
RELNOTES: None.
PiperOrigin-RevId: 163728291
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 163343931
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Broke bazel_apple_rules
*** Original change description ***
Make all WithLegacySkylarkName providers declared providers.
RELNOTES: None
PiperOrigin-RevId: 163054821
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 163042362
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Almost) all native declared providers are accessed as such and not as
native non-declared providers (inheritors of TransitiveInfoCollaction).
There are still three providers that use
TransitiveInfoCollection.WithLegacySkylarkName mechanism, I'll address
them in the follow-up CL.
RELNOTES: None.
PiperOrigin-RevId: 161655315
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 160675033
|
|
|
|
|
|
|
| |
PathFragment.TO_PATH_FRAGMENT
RELNOTES: None.
PiperOrigin-RevId: 160668541
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 157857216
|
|
|
|
| |
PiperOrigin-RevId: 155562588
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `structured_resources` path stemming used by `objc_library` and
`objc_bundle_library` no longer breaks if one of these rules tries to
reference a label with an explicit repository prefix. Previously,
using "@foo//bar:baz" in such a rule would fail because the individual
files would retain their "external/foo/" prefix but the owner path
against which those files were relativized would not have it because
of the use of getPackageFragment() instead of
getPackageIdentifier().getSourceRoot().
RELNOTES: None.
PiperOrigin-RevId: 155409464
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/5f31944b8942818aaf53571c76f5c6a9a9dafc72: Custom module map for j2objc_library
Automated g4 rollback of commit e7fe50aa727df9ef0a3d37fa258d017971035515.
*** Reason for rollback ***
Roll forward. The bzl change is removed because it has to be submitted after next Blaze release.
*** Original change description ***
Automated g4 rollback of commit 5f31944b8942818aaf53571c76f5c6a9a9dafc72.
*** Reason for rollback ***
This caused some build breaks.
*** Original change description ***
Custom module map for j2objc_library
PiperOrigin-RevId: 154726197
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
This caused some build breaks.
*** Original change description ***
Custom module map for j2objc_library
PiperOrigin-RevId: 154608761
|
|
|
|
| |
PiperOrigin-RevId: 154606005
|
|
|
|
|
|
|
|
|
|
|
|
| |
'create' method.
This paves the way for changing PathFragment to e.g. an abstract class with multiple subclasses. This way we can split out the windows-specific stuff into one of these concrete classes, making the code more readable and also saving memory (since the shallow heap size of the NonWindowsPathFragment subclass will hopefully be smaller than that of the current PathFragment).
This also lets us pursue gc churn optimizations. We can now do interning in PathFragment#create and can also get rid of unnecessary intermediate PathFragment allocations.
RELNOTES: None
PiperOrigin-RevId: 152145768
|
|
|
|
|
|
|
|
| |
path. In the process, rename and replace the incorrectly named ObjcCommon.Builder#addUserHeaderSearchPaths
--
PiperOrigin-RevId: 147038434
MOS_MIGRATED_REVID=147038434
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 146813606
MOS_MIGRATED_REVID=146813606
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 146612144
MOS_MIGRATED_REVID=146612144
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 146487282
MOS_MIGRATED_REVID=146487282
|
|
|
|
|
|
|
|
|
|
| |
the target type
This allows us to correctly analyze the type of alias targets
--
PiperOrigin-RevId: 142582188
MOS_MIGRATED_REVID=142582188
|
|
|
|
|
|
|
|
|
|
| |
framework directories."
This is a rollforward of the first attempt, which broke swift rules.
--
PiperOrigin-RevId: 141210876
MOS_MIGRATED_REVID=141210876
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Fails test_swift_import_objc_framework of //src/test/shell/bazel/apple:bazel_apple_test
Tested on: https://cr.bazel.build/7611/
Fixes #2179.
*** Original change description ***
Split ObjcProvider.framework_dir into static and dynamic framework directories.
***
--
Change-Id: I10db5e14b219bc921bff72c45fab1455be8fa25a
Reviewed-on: https://cr.bazel.build/7311
PiperOrigin-RevId: 141043141
MOS_MIGRATED_REVID=141043141
|
|
|
|
|
|
|
|
|
|
|
| |
Previously there was no difference between static and dynamic framework directories in how they affected link actions.
However, there will be a difference moving forward:
Dynamic framework files and their directories will be propagated up dynamic library edges, and static frameworks will not.
(If an app A depends on a dylib B which depends on a dylib C, A should not link any static framework dependencies of C, but should link against C itself.)
--
PiperOrigin-RevId: 140869357
MOS_MIGRATED_REVID=140869357
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=140068224
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=131055419
|