| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This cl adds Skylark constants allowing users to specify which C++ action they
want for the feature configuration Skylark API. This is done by exposing a
Skylark file at @bazel_tools//tools/cpp:action_names.bzl.
Skylark api to the C++ toolchain doc:
https://docs.google.com/document/d/1g91BWJITcYw_X-VxsDC0VgUn5E9g0kRBGoBSpoO41gA/edit#.
Progress on #4571.
RELNOTES: None.
PiperOrigin-RevId: 199596778
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The difference between them is that user_link_flags will stay after we remove
legacy fields from the crosstool.
This is an encore of https://github.com/bazelbuild/bazel/commit/2661abb96b1fe51fb726a63eb08698564a82eb20 after mitigating the memory regression.
Original cl regressed 12mb (on a big enough internal project :):
objsize chg instances space KB class name
------------------------------------------------------
24 +0 190265 4459 KB com.google.common.collect.ImmutableMapEntry
40 +0 95154 3716 KB com.google.common.collect.RegularImmutableMap
47 -2 95154 2230 KB [Ljava.util.Map$Entry;
44 -1 95154 2230 KB [Lcom.google.common.collect.ImmutableMapEntry;
24 +0 95149 2230 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$MapVariables
16 +0 95149 1486 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$StringSequence
89 +0 3188 176 KB [B
64 -8 0 -743 KB com.google.devtools.build.lib.rules.cpp.LinkCommandLine
76 +0 -1918 -1323 KB [Ljava.lang.Object;
24 +0 -95149 -2230 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$SingleVariables
------------------------------------------------------
The reason was that before legacy_link_flags were the only build variable
patched because of thinlto in CppLinkActionBuilder, so it used optimized
SingleVariables subclass. With the split, the patched variables instance had 2
variables therefore it received the full blown Variables instance. That
accounted for the ~7mb.
The fix was to move the patching logic to the initial link variables creation
and not to create patched variables at all. Now the regression is ~4.8mb, which
is perfectly expected since I introduce another variable and this is the
overhead of additional hashmap entry:
objsize chg instances space KB class name
------------------------------------------------------
24 +0 190418 4462 KB com.google.common.collect.ImmutableMapEntry
44 +1 31 1487 KB [Lcom.google.common.collect.ImmutableMapEntry;
16 +0 95149 1486 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$StringSequence
47 +0 31 744 KB [Ljava.util.Map$Entry;
89 +0 5723 315 KB [B
24 +0 5721 134 KB java.lang.String
64 -8 0 -743 KB com.google.devtools.build.lib.rules.cpp.LinkCommandLine
76 +0 -2387 -840 KB [Ljava.lang.Object;
24 +0 -95149 -2230 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$SingleVariables
------------------------------------------------------
I'll pay this dept back once we get rid of legacy crosstool fields (= removal of
legacy_link_flags variable).
RELNOTES: None.
PiperOrigin-RevId: 197574153
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change makes Bazel respect artifact name patterns specified in
CROSSTOOL.
Users cannot specify any arbitrary name pattern, it must ends with allowed
extensions. For example, for dynamic library, it can only ends with .so,
.dylib or .dll, otherwise Bazel throws an error.
Change-Id: I21d9e6fa7c3a282e1a9b8ff29679b00925cddb33
PiperOrigin-RevId: 197553413
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks perf regtest
*** Original change description ***
Split user_link_flags from legacy_link_flags
The difference between them is that user_link_flags will stay after we remove
legacy fields from the crosstool.
RELNOTES: None.
PiperOrigin-RevId: 197180518
|
|
|
|
|
|
|
|
| |
The difference between them is that user_link_flags will stay after we remove
legacy fields from the crosstool.
RELNOTES: None.
PiperOrigin-RevId: 196940832
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 195777400
|
|
|
|
|
|
|
|
|
| |
Staticness is confusing, I always have to investigate which is Staticness and
which is LinkStaticness, and even in isolation staticness is not a great name. I
believe LinkerOrArchiver is a better name :)
RELNOTES: None.
PiperOrigin-RevId: 195674810
|
|
|
|
|
|
|
|
| |
Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command l...
RELNOTES:
Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent.
PiperOrigin-RevId: 195258075
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Still causes a memory regression
*** Original change description ***
Consolidating start/end lib archive expansion Take 2
Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command l...
RELNOTES:
Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent.
PiperOrigin-RevId: 194970156
|
|
|
|
|
|
|
|
| |
Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command l...
RELNOTES:
Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent.
PiperOrigin-RevId: 194847987
|
|
|
|
| |
PiperOrigin-RevId: 194506134
|
|
|
|
|
|
|
|
| |
Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command line.
RELNOTES:
Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent.
PiperOrigin-RevId: 194400112
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dynamic libraries
Term runtime input had 2 meanings in CppLinkAction:
1) input needed at runtime - dynamic library
2) input corresponding to the C++ runtime (libstdc++ or libc++)
This confused me and therefore the code :) This cl cleans this up to some extent by:
* renaming runtimeInput to runtimesInput, to at least give the reader a chance to catch the difference :)
* treating runtimesInputs as normal linker inputs, also downstream in CppLinkAction and LinkCommandLine
* Simplifying LibrariesToLinkCollector by removing explicit runtimesHandling.
RELNOTES: None
PiperOrigin-RevId: 194046439
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 191713379
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For CLIF it doesn't matter whether we use PIC or no-PIC, the important thing
is we get an output protobuf. Before https://github.com/bazelbuild/bazel/commit/35773928532c132e3229b490ad98f4ebfd3e5770, using no-PIC was hardcoded.
In this CL it was decided to generate PIC instead because the toolchains used
by CLIF targets appeared to all have needsPic. In b/73955395 it has been shown
not to be the case.
In this CL I'm changing the logic again to use no-PIC for CLIF and to
circumvent the logic that checks what the configuration and the toolchain say.
At the same time, SWIG also used the method setGenerateNoPic() after the
variable onlySingleOutput was removed in https://github.com/bazelbuild/bazel/commit/4e9c9f93b15dd2594097644c6b9ca5a579c712fb. In this CL I use the
enum to apply PIC and no-PIC in the same cases as before for SWIG.
This CL also refactors the methods and boolean variables used to determine whether to use PIC or not, hopefully making it clearer.
RELNOTES:none
PiperOrigin-RevId: 190615548
|
|
|
|
|
|
|
|
|
|
|
| |
We don't need to separate them into 4 different flavours, all crosstools define
them identically anyway.
RELNOTES: CppRules: Unified action_configs for static libraries
From now on only c++-link-static-library is read.
PiperOrigin-RevId: 188726352
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this cl toolchain author can specify different flags for linking shared
library produced by cc_library and a shared library produced by cc_binary.
This is what is needed to remove linking_mode_flags - MOSTLY_STATIC_LIBRARIES
from the crosstool. What this linking mode was used for was to separate when we
link transitive shared library from cc_binary and when we link this
little-and-not-really-useful-outside-of-bazel nodeps shared library in cc_library.
RELNOTES: CcToolchain: Introduced action_config for "c++-link-transitive-dynamic-library"
PiperOrigin-RevId: 187523334
|
|
|
|
|
|
|
|
|
| |
MANDATORY_LINK_TARGET_TYPES has not been in use since d83d9bf1 was
released.
Closes #3869.
PiperOrigin-RevId: 171688095
|
|
|
|
|
|
|
|
| |
the general collection interface (e.g. List) with an immutable type (e.g. ImmutableList).
For constant field declarations, you should use the immutable type (such as ImmutableList) instead of the general collection interface type (such as List). This communicates to your callers important semantic guarantees.
PiperOrigin-RevId: 152223147
|
|
|
|
|
|
|
|
| |
This requires passing linkopts through CrosstoolCompilationSupport into the 'legacy_link_flags' feature, as is done in c++.
--
PiperOrigin-RevId: 148911500
MOS_MIGRATED_REVID=148911500
|
|
|
|
|
|
|
|
| |
1) Uses clang++ instead of clang.
2) Add -stdlib=libc++ and -std=gnu++11 linker args
--
MOS_MIGRATED_REVID=140049151
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following link features are *not* implemented yet:
1) Objc++ linking semantics
2) Dead stripping
3) --should_prioritize_static_libs
4) DSYM generation
5) Coverage support
6) Swift interop
7) Linkmap
--
MOS_MIGRATED_REVID=139232434
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=130938527
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=130547971
|
|
|
|
|
|
|
| |
LinkerInput#getArtifactCategory() and use this information to remove one use of LINK_LIBRARY_FILETYPES.
--
MOS_MIGRATED_REVID=130400793
|
|
|
|
|
|
|
| |
our C++ rules (except from precondition checks)
--
MOS_MIGRATED_REVID=130396421
|
|
|
|
|
|
|
|
|
|
|
| |
1) In ExperimentalObjcLibrary, if static linking is required, signal CcLibraryHelper to create a static link action and pass in the necessary variables/link action input.
2) Add a new link type (Link.LinkTargetType.OBJC_STATIC_LIBRARY). This involves changes to Link and LinkCommandLine.
3) For this new link type, implement static linking the OSX CROSSTOOL. Also add tools in the crosstool package that point at libtool, which performs the archiving.
--
MOS_MIGRATED_REVID=130022410
|
|
|
|
|
|
|
|
|
| |
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 is a re-submission of commit 99de0d07574f808fee36826289cb1f5c83e3b3e0 (rolled back in commit eff8b365c172b7e904ac6f7bba0c893fed7c91a8) and a few tweaks: - The fix for the bug that caused the rollback (see line 888 in CppModel.java -- we now use addNonCodeInputs() instead of addObjectFiles() to pass in the processed header tokens)
- A few extra assertions
- A test case
- The re-submission of the parts of commit 603b540bbcd7414cd3e2c0b92c1c8985b035e41b that were also rolled back as collateral damage.
The bug report didn't contain a precise reproduction, but the bug is trivial enough that I'm comfortable with things this way.
--
MOS_MIGRATED_REVID=129872117
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Makes blaze unable to build //third_party/stl
IllegalArgumentException: complex.h.processed
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:127)
at com.google.devtools.build.lib.util.Preconditions.checkArgument(Preconditions.java:38)
at com.google.devtools.build.lib.rules.cpp.CppLinkActionBuilder.addObjectFile(CppLinkActionBuilder.java:831)
NOT a clean rollback; conflict in one file (CppCompilationContext.java).
So this also partially rolls back commit 603b540bbcd7414cd3e2c0b92c1c8985b035e41b (just the change in that file).
*** Original change description ***
Cleanup: store non-code inputs to link actions separately.
--
MOS_MIGRATED_REVID=129798636
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=129743936
|
|
|
|
|
|
|
|
|
| |
The multi-layered transformation (base -> base.pic -> base.pic.pcm -> base.pic.pcm.d) is kinda ugly, but is preferable to having 22 separate, mostly orthogonal artifact categories.
It's actually untested what happens if we put these new name patterns into the CROSSTOOL file.
--
MOS_MIGRATED_REVID=129423055
|
|
|
|
|
|
|
| |
infrastructure to allow other artifact categories (such as debug symbols or compiler outputs) to be defined in other changes.
--
MOS_MIGRATED_REVID=128495797
|
|
|
|
|
|
|
|
|
| |
action_config to configure the build. Otherwise, revert to hard-coded behavior.
This change is designed to provide backwards-compatible support for crosstools that describe platform-specific linking semantics.
--
MOS_MIGRATED_REVID=123748494
|
|
|
|
|
|
|
|
|
| |
LocalGccStrategy / LocalLinkStrategy with SpawnGccStrategy / SpawnLinkStrategy.
RELNOTES: C++ compile actions run in a sandbox now on systems that support sandboxed execution.
--
MOS_MIGRATED_REVID=106299043
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
--
MOE_MIGRATED_REVID=85702957
|