| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
This is slightly more descriptive, and we will potentially want to use the name Root for a broader concept shared between ArtifactRoot and RootedPath.
PiperOrigin-RevId: 182082367
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current checks used in several places for whether an LTO indexing
step is needed only looked for direct LTO bitcode inputs. Instead we should
use the existing hasLtoBitcodeInputs() method to look both at the direct
inputs as well as inputs on all LibraryToLink. This was already used in
similar checking on the CppBinary. With this change, all places that
test for needing an LTO indexing step use the correct interface.
RELNOTES: None
PiperOrigin-RevId: 179812972
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rollforward of https://github.com/bazelbuild/bazel/commit/c861c0afd9a4df283936218b9e5b33c452b07c95 after fixing fake link actions.
*** Original change description ***
Rollback of 178106899.
RELNOTES: Linkstamping is now a separate and full-blown CppCompileAction, it's
no longer a part of linking command.
PiperOrigin-RevId: 178760072
|
|
|
|
| |
PiperOrigin-RevId: 178384991
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This cl replaces entire hardcoded linkstamping command line generation with a
separate action. Instead of generating bash command
to compile linkstamp and prepending it to the standard link command line, this
cl creates a special action that link action depends on.
I kept linkstamp action registration in the CppLinkActionBuilder (and
GoCompilationHelper internally) to keep the cl shorter and change more
localized. I also didn't remove linkstamps and buildInfoHeaderArtifacts from
CppLinkAction to stay compatible with extra actions api. Both issues and
corresponding cleanups will be addressed in separate cls.
RELNOTES: Linkstamping is now a separate and full-blown CppCompileAction, it's
no longer a part of linking command.
PiperOrigin-RevId: 178106899
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ThinLTO and static linking of test suites is a bad combination since it results in a combinatorial explosion of the ThinLTO backends - each object file needs a separate LTO backend action per target. If you are static linking O(N) objects, and have O(M) targets, with ThinLTO you will get O(N*M) LTO backend jobs. This is because the whole program optimization step is per-target, and may make different decisions affecting the object files. With dynamic linking it isn't a problem, since the ThinLTO optimization happens at the .so level, which are shared across tests. And for statically-linked cc_binary it hasn't been an issue since typically only a single target is built at a time, unlike tests.
In general it isn't incredibly useful to run tests with ThinLTO, although most projects are in the habit of running their tests with the same options that they use to optimize their main binary (and most blueprints seem to be set up to share options between them). With ThinLTO since it is doing whole-program optimization, you are getting different whole-program optimizations for the main binary and each test binary, so it isn't the case that this will optimize the tests in the same exact way as the main binary anyway.
Therefore, when creating LTO backends for statically-linked *_test targets, skip the LTO indexing stage, and create (or use if already created) shared dummy LTO backend actions for each library. These LTO backends are fed an empty index, so they don't do any whole program optimization and are safe to share.
Enable this under a new feature so that we can enable it by default via blazerc but provide a facility to disable if needed.
RELNOTES: None
PiperOrigin-RevId: 177495858
|
|
|
|
|
|
|
|
|
|
|
| |
CppHelper. In CppHelper, CcToolchainProvider and CppConfiguration are used
sepereately, allowing toolchain information to be removed from
CppConfiguration.
This is necessary to introduce hermetic toolchains, which require that
toolchain information be seperated from the configuration, into the c++ rules.
PiperOrigin-RevId: 176694160
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Android's mechanism for automatically linking native deps does not currently support linker scripts. A dependency cc_library can specify the linker script in the linkopts and include it in its deps, but since the artifact is not provided as an input to the generated link action, this results in an error. This change provides the missing inputs and makes this work.
RELNOTES: Support for linker scripts in NativeDepsHelper (e.g., android_binary)
PiperOrigin-RevId: 172963605
|
|
|
|
|
|
|
|
|
| |
Currently CppLinkActionBuilder is not using CppSemantics, but it will when
we use full CppCompileAction for linkstamp compiles. This cl is a preparation
for that.
RELNOTES: None.
PiperOrigin-RevId: 170467826
|
|
|
|
|
|
|
|
|
| |
While we don't generate .dwp files for shared libraries, the link still expects the object files to contain split debug info.
Enhanced tests to ensure the cc_library LTO backend actions always have the expected outputs/build variable, regardless of linking static or not.
RELNOTES: NONE
PiperOrigin-RevId: 166853630
|
|
|
|
|
|
| |
As suggested in readability review for https://github.com/bazelbuild/bazel/commit/2789c97149a1f253b659aa0f2401f44705a3258f. Ended up being a fair number of changes, but I think I got them all.
PiperOrigin-RevId: 163975846
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for setting up the LTO indexing step when the inputs
contain bitcode.
Added a python BuildViewTestCase that provokes this, as well as a
ThinLTO GoogleBuildIntegrationTestCase to the existing NativeDeps
testing.
PiperOrigin-RevId: 163827441
|
|
|
|
|
|
|
| |
Show meaningful message instead.
RELNOTES: None.
PiperOrigin-RevId: 161196096
|
|
|
|
|
|
|
|
| |
And while at it cleanup all the calls of CppHelper.getToolchain and
CppHelper.getFdoSupport.
RELNOTES: None.
PiperOrigin-RevId: 156716291
|
|
|
|
|
|
|
|
|
|
|
|
| |
'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
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was suggested in the review for unknown commit, which adds ThinLTO support
to another client of CppLinkActionBuilder.
The change required changing the constructor to take a FdoSupportProvider
object instead of a FdoSupport object, so required changes to all callers.
--
PiperOrigin-RevId: 150060046
MOS_MIGRATED_REVID=150060046
|
|
|
|
|
|
|
|
|
|
| |
":cc_toolchain" in RuleContext, instead take the provider from users and pass it around to where it is used.
This gives J2ObjcAspect the ability to specify the C++ toolchain attribute under a different name to avoid attribute conflicts with attached rules that have already declared attribute ":cc_toolchain".
--
PiperOrigin-RevId: 147358325
MOS_MIGRATED_REVID=147358325
|
|
|
|
|
|
|
|
| |
Doesn't add much on top of the Iterable version in the current state of things, and it is too easy to confuse with addString.
--
PiperOrigin-RevId: 141300940
MOS_MIGRATED_REVID=141300940
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Roll forward with fixes.
--
MOS_MIGRATED_REVID=131224077
|
|
|
|
|
|
|
| |
0978a8ea1593ef204ea97155014f76baba2508c5 broke it.
--
MOS_MIGRATED_REVID=130496094
|
|
|
|
|
|
|
| |
The only place we now don't handle InterruptedException is in the action graph created after analysis, since I'm not sure that will be around for that much longer.
--
MOS_MIGRATED_REVID=130327770
|
|
|
|
|
|
|
|
|
| |
It's currently only used for sanity checks, but the idea is that we'll use this field to decide what to do with a given linker input instead of inferring things from its file name.
Also make artifact name creation a bit simpler by using the same set of variables for compiler and linker outputs.
--
MOS_MIGRATED_REVID=129990944
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This doesn't do anything yet, it's in preparation for the execroot rearranging
change. The execroot will have one bazel-out per repo, so it'll look like:
execroot/
repo1/
bazel-out/
local-fastbuild/
bin/
repo2/
bazel-out/
local-fastbuild/
bin/
genfiles/
repo3/
bazel-out/
local-fastbuild/
testlogs/
and so on. Thus, any output path (getBinDirectory() & friends) needs to know
what the repo name is. This changes so many places in the code I thought it
would be good to do separately, then just flip the functionality in the
execroot-rearranging commit.
While I was poking around, I changed all of the refs I could from getPackageRelativeArtifact() to getBin/GenfilesArtifact(), so that 1) rule implementation don't have to know as much about roots and 2) they'll be more isolated from other output dir changes.
`bazel info` and similar just return roots for the main repository.
The only "change" is passing around a target label in the Java rules.
Continues work on #1262.
--
MOS_MIGRATED_REVID=129985336
|
|
|
|
|
|
|
| |
called at places where a CcToolchainProvider is near so that we can use information in it to infer how each input file is linked.
--
MOS_MIGRATED_REVID=129729628
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=127221256
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Broke some targets
--
MOS_MIGRATED_REVID=126574275
|
|
|
|
|
|
|
| |
Android split transitions.
--
MOS_MIGRATED_REVID=126378169
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
legacy_native_support makes it so that Bazel copies .so's instead of linking.
This allows Bazel to include third-party native code without running an NDK.
Turning it off allows Bazel to actually compile native code, but at the cost
of this copy case no longer working without an NDK, and creating an unnecessary
shared library which will most likely never be used.
This CL makes it so that if no actual source code or static libraries are
in the transitive closure, the linker is not run at the android_binary level.
This means that legacy_native_support as a separate concept can be removed,
and it is - the attribute remains, but is a no-op. This will be removed in
a future change. The matching flag (--legacy_android_native_support) has
already been removed.
RELNOTES: The link mode for Android native code is now automatically determined
based on the transitive closure of cc_libraries, and legacy_native_support is
now a no-op. --legacy_android_native_support has been removed.
--
MOS_MIGRATED_REVID=126244755
|
|
|
|
|
|
|
|
| |
Before this patch we would store expanded transitive include files in
CcLinkParams.
--
MOS_MIGRATED_REVID=123103815
|
|
|
|
| |
MOS_MIGRATED_REVID=121353990
|
|
|
|
|
|
|
| |
Reduces garbage.
--
MOS_MIGRATED_REVID=109914243
|
|
|
|
|
|
|
|
|
|
|
| |
The headers were modified with
`find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'`
And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan.
The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand.
--
MOS_MIGRATED_REVID=103938715
|
|
|
|
|
|
|
| |
Only one for now, as we need to migrate internally.
--
MOS_MIGRATED_REVID=102477370
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=102332437
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Refactor the ndk toolchain generation to properly set the dynamic and static
runtime lib filegroups.
- Enable the runtime filegroups.
- Change the NativeDepsHelper to work as documented - mostly static means
statically linking the runtime filegroups; but only for Android to remain
backwards compatible with other users of NativeDepsHelper.
- This is safe as we don't use runtime filegroups internally for Android...
yet.
- Clean up the NativeDepsHelper a bit.
Fixes #392.
Next steps are to make this configurable at the android_binary level. We
should also disable whole-archive in this case.
--
Change-Id: I95b0ce45d8b3adcf5424544c92ec30102b7fac6b
Reviewed-on: https://bazel-review.googlesource.com/1879
MOS_MIGRATED_REVID=102239337
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=101344826
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=101218538
|
|
|
|
|
|
|
|
|
| |
of the artifacts in a way that checks that they are under the package directory.
The exception is nativedeps, whose link actions are shared, and thus they cannot be at a package-specific location.
--
MOS_MIGRATED_REVID=101216949
|
|
|
|
|
|
|
| |
RuleContext.getShareableArtifact() calls where the former method is used to create the outputs of shared actions.
--
MOS_MIGRATED_REVID=101116694
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=99819719
|
|
|
|
|
|
|
|
|
|
|
|
| |
rules that can be removed.
What is left:
- The outputs of ExtractInclusionsAction. I think this action is shared between multiple rules that have the same generated file in srcs, so this call site is legitimate.
- Creating the solib symlinks. This is not a shared action, but these need to be in the same directory so that the RPATH is not too long, so we must live with this for the time being.
- FDO, which is beyond salvation. The artifacts under the FDO root don't really conform to the usual "only under the package directory" convention.
--
MOS_MIGRATED_REVID=99551394
|
|
|
|
|
|
|
|
|
| |
Remove an unnecessary intermediate method in CcBinary and provide a helper
method in CcLinkAction.Builder that simplifies several call sites that just
want to add CcLinkParams to the link action.
--
MOS_MIGRATED_REVID=99172303
|
|
|
|
|
|
|
|
| |
This simplifies the callers and we get better consistency - the getBuildInfo
must use matching AnalysisEnvironment and RuleContext objects.
--
MOS_MIGRATED_REVID=91815339
|
|
--
MOS_MIGRATED_REVID=90828000
|