| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
| |
If no_stripping feature is enabled, then strip action config is not
necessary, building stripped binary will just copy the orignial binary.
Fix https://github.com/bazelbuild/bazel/issues/3482
Also fixed CI breakage:
https://github.com/bazelbuild/bazel/issues/3505
Change-Id: Ie78fe174c42248c9b3e930008eef96dcd1864741
PiperOrigin-RevId: 164237588
|
|
|
|
|
|
|
|
|
| |
Add SpawnAction.Builder#setProgressMessageNonLazy for dynamic strings. This should help guide users to the right method.
This also helped find a few methods I'd missed previously that could use a constant-string version.
RELNOTES: None
PiperOrigin-RevId: 164150264
|
|
|
|
|
|
|
|
|
|
| |
This cl introduces new action_config named 'strip' for the strip action. While
at it, it fixes support for executionRequirements.
Fixed #209
RELNOTES: 'strip' action is now configured via feature configuration
PiperOrigin-RevId: 164110478
|
|
|
|
|
|
|
|
|
|
| |
Consumers using spawn action builder now have access to handy overloads that behind the scene do a lazy String.format. In 95% of cases progress messages are expressible as 0, 1, or 2 argument String.formats.
This saves memory because the format string is constant and shared between all actions, and the captured subjects are usually live on the heap anyway (eg. labels).
Skylark still computes its progress messages eagerly. If we want similar savings there I'd have to follow up with a Skylark proposal.
PiperOrigin-RevId: 164068816
|
|
|
|
|
|
|
| |
Also fix the remaining violations.
RELNOTES: None.
PiperOrigin-RevId: 163391215
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This cl introduces new action_config type for Crosstool named 'generic'. This
can be used to set the value of CC_FLAGS make variable using much more
expressive mechanism (action_configs + features) than previous make_variable
Crosstool messages. This has been requested by the C++ LPT.
However, as FeatureConfiguration needs RuleContext, CC_FLAGS cannot be
computed using configuration only anymore. Also, FeatureConfiguration is C++
rules specific class, and Bazel build-base cannot depend on it. Therefore we
cannot use FeatureConfiguration for ExtraActions, for example. Because it cannot
be made perfect, this cl is not updating all the possible places that expand
make variables but limits the scope to:
* genrule (the only widely used rule that often expands make variables)
* *_test (CC_FLAGS is used by Tensorflow in the 'args' attribute)
* cc_rules (people sometimes set 'copts' to something like:
"-DCC_STRING=\\\"$(CC)\\\" -DCC_FLAGS_STRING=\"$(CC_FLAGS)\""
The long term plan is to use Skylark C++ API to get C++ command lines, so
CC_FLAGS together with this inconsistent solution will be removed.
RELNOTES: CC_FLAGS can be defined using 'generic' action_config in CROSSTOOL
PiperOrigin-RevId: 157202883
|
|
|
|
|
|
|
|
| |
And while at it cleanup all the calls of CppHelper.getToolchain and
CppHelper.getFdoSupport.
RELNOTES: None.
PiperOrigin-RevId: 156716291
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Fixes memory issue that caused this CL to be rolled back.
*** Original change description ***
Automated g4 rollback of commit cbbb423663b154d82e3dfa5e9a56839583987999.
*** Reason for rollback ***
Need to roll this back as part of http://b/38171368
*** Original change description ***
RELNOTES: Effectively remove sysroot from CppConfiguration and allow it to use select statements.
PiperOrigin-RevId: 155651879
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Need to roll this back as part of http://b/38171368
*** Original change description ***
RELNOTES: Effectively remove sysroot from CppConfiguration and allow it to use select statements.
PiperOrigin-RevId: 155547813
|
|
|
|
|
|
| |
use select statements.
PiperOrigin-RevId: 155480011
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Original CL was rolled backed incorrectly. See post-submit discussion on http://https://github.com/bazelbuild/bazel/commit/7beadb7277453efec7e12b925005e7f0e003b592.
*** Original change description ***
Automated g4 rollback of commit 38b835097f9ae9a6062172b8a33ec2e2d1edde20.
*** Reason for rollback ***
Breaking Bazel build on linux, see http://ci.bazel.io/job/bazel-tests/733/
Repro: bazel build //src/test/java/com/google/devtools/build/lib:packages_test
Found by bisecting.
*** Original change description ***
Only allocate some formerly frequently allocated PathFragment objects once.
This reduces both gc churn and retained memory usage.
RELNOTES: None
PiperOrigin-RevId: 154839279
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaking Bazel build on linux, see http://ci.bazel.io/job/bazel-tests/733/
Repro: bazel build //src/test/java/com/google/devtools/build/lib:packages_test
Found by bisecting.
*** Original change description ***
Only allocate some formerly frequently allocated PathFragment objects once.
This reduces both gc churn and retained memory usage.
RELNOTES: None
PiperOrigin-RevId: 154821457
|
|
|
|
|
|
| |
This reduces both gc churn and retained memory usage.
PiperOrigin-RevId: 154718782
|
|
|
|
|
|
|
|
|
|
|
|
| |
'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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow toolchains to specify precisely the files required to
run code coverage tools (e.g. gcov). If not specifed, default
to the existing behaviour of supplying the whole crosstool.
RELNOTES[NEW]: Optional coverage_files attribute to cc_toolchain
--
PiperOrigin-RevId: 150878146
MOS_MIGRATED_REVID=150878146
|
|
|
|
|
|
|
|
| |
--experimental_objc_crosstool=all
--
PiperOrigin-RevId: 150066766
MOS_MIGRATED_REVID=150066766
|
|
|
|
|
|
|
|
| |
Note that I also have to make some changes to cpp files to add the ability to specify a suffix for linked artifacts. This helps to avoid an artifact conflict between proto_library and J2ObjcAspect acting on proto_library, where both will create an archive file. J2ObjcAspect will simply generate a "_j2objc.a" archive instead of ".a" archive.
--
PiperOrigin-RevId: 148135630
MOS_MIGRATED_REVID=148135630
|
|
|
|
|
|
|
|
| |
and toolchain contexts.
--
PiperOrigin-RevId: 148104218
MOS_MIGRATED_REVID=148104218
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Broke tests on CI: http://ci.bazel.io/job/bazel-tests/570/
*** Original change description ***
Roll forward execroot change
RELNOTES[INC]: Previously, an external repository would be symlinked into the
execution root at execroot/local_repo/external/remote_repo. This changes it to
be at execroot/remote_repo. This may break genrules/Skylark actions that
hardcode execution root paths. If this causes breakages for you, ensure that
genrules are using $(location :target) to access files and Skylark rules are
using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc.
functions. Cust...
--
PiperOrigin-RevId: 147833177
MOS_MIGRATED_REVID=147833177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RELNOTES[INC]: Previously, an external repository would be symlinked into the
execution root at execroot/local_repo/external/remote_repo. This changes it to
be at execroot/remote_repo. This may break genrules/Skylark actions that
hardcode execution root paths. If this causes breakages for you, ensure that
genrules are using $(location :target) to access files and Skylark rules are
using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc.
functions. Custom crosstools that hardcode external/<repo> paths will have to
be updated.
Issue #1262.
--
PiperOrigin-RevId: 147726370
MOS_MIGRATED_REVID=147726370
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a configuration to be passed into the cc backend and used to scope output artifacts.
Artifacts involved:
(1) Object files: see change in CppHelper, CppModel, CppCompileActionBuilder
(2) Archive files: see change in CppModel
(3) Archive objfile list: see change in ObjcVariablesExtension.
Other little things that needed to be cleaned up to enable this:
(1) neverlink set on objc archive actions. Without neverlink, colliding solib artifacts are generated from the two archives arising from the multi-arch split.
(2) Toolchain selection in CrosstoolCompilationSupport uses passed-in configuration instead of :cc_toolchain attribute. This allows for each of the compiles spawned from apple_binary.srcs to select the correct toolchain based on the child configuration.
--
PiperOrigin-RevId: 147550618
MOS_MIGRATED_REVID=147550618
|
|
|
|
|
|
|
|
|
|
| |
":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
|
|
|
|
|
|
|
|
| |
CppCompileActions that to be executed at execution time.
--
PiperOrigin-RevId: 147163077
MOS_MIGRATED_REVID=147163077
|
|
|
|
|
|
|
|
|
|
| |
":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: 146920294
MOS_MIGRATED_REVID=146920294
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flag, the headers of a target are compiled into a C++ module instead of being
parsed as their own translation unit. The module otherwise remains unused.
This way, parse_headers can be used to get a codebase ready for C++ modules.
parse_headers currently already gets close, but there are still ways in which a
header can be modules-incompatible although it parses fine.
--
PiperOrigin-RevId: 145729231
MOS_MIGRATED_REVID=145729231
|
|
|
|
|
|
|
| |
RELNOTES: cc_proto_library generates C++ code from proto_library rules.
--
MOS_MIGRATED_REVID=140680034
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks TensorFlow and other Bazel jobs on ci.bazel.io
*** Original change description ***
Change execution root for external repositories to be ../repo
Some of the important aspect of this change:
* Remote repos in the execution root are under output_base/execroot/repo_name, so the prefix is ../repo_name (to escape the local workspace name).
* Package roots for external repos were previously "output_base/", they are now output_base/external/repo_name (which means source artifacts always have a relative path from their repository).
* Outputs are under bazel-bin/external/repo_name/ (or similarly under genfiles). Note that this is a bit of a change from how this was implemented in the previous cl.
Fixes #1262.
RELNOTES[INC]: Previously, an external repository would be symlinked into the
execution root at execroot/local_repo/external/remote_repo. This changes it to
be at execroot/remote_repo. This may break genrules/Skylark actions that
hardcode execution root paths. If this causes breakages for you, ensure that
genrules are using $(location :target) to access files and Skylark rules are
using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc.
functions.
Roll forward of bdfd58a.
--
MOS_MIGRATED_REVID=133709658
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the important aspect of this change:
* Remote repos in the execution root are under output_base/execroot/repo_name, so the prefix is ../repo_name (to escape the local workspace name).
* Package roots for external repos were previously "output_base/", they are now output_base/external/repo_name (which means source artifacts always have a relative path from their repository).
* Outputs are under bazel-bin/external/repo_name/ (or similarly under genfiles). Note that this is a bit of a change from how this was implemented in the previous cl.
Fixes #1262.
RELNOTES[INC]: Previously, an external repository would be symlinked into the
execution root at execroot/local_repo/external/remote_repo. This changes it to
be at execroot/remote_repo. This may break genrules/Skylark actions that
hardcode execution root paths. If this causes breakages for you, ensure that
genrules are using $(location :target) to access files and Skylark rules are
using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc.
functions.
Roll forward of bdfd58a.
--
MOS_MIGRATED_REVID=133606309
|
|
|
|
|
|
|
| |
mentioned in the dynamic_runtime_libs attribute.
--
MOS_MIGRATED_REVID=132676097
|
|
|
|
|
|
|
|
|
|
|
| |
Chipping away at making the big CL for #1262 smaller. Only runfiles paths
are different right now, so this makes getPathUnderExecRoot and getSourceRoot
return the same thing. Also corrected a couple places where
Label.EXTERNAL_PATH_PREFIX and Label.EXTERNAL_PACKAGE_NAME were being used
incorrectly.
--
MOS_MIGRATED_REVID=132671081
|
|
|
|
|
|
|
|
|
| |
assert that solib symlinks always point to dynamic libraries.
Note that this makes it possible to crash Bazel with a malicious CROSSTOOL file, but since we are migrating to cc_toolchain_suite which raises a user-friendly error earlier, this is okay.
--
MOS_MIGRATED_REVID=130915262
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
execroot change
This is in prep for making the execution root path for external repositories
../repo_name (instead of external/repo_name). Right now, the getRunfilesPath() returns that path, so that is renamed getExecRoot() (since the runfiles are really just a reflection of the execRoot structure). getSourceRoot() replaces getPathFragment, which has always been a confusing name (it's not clear from the name
what the difference is between it and getPackageFragment()). It returns the relative path to source files for external repositories (external/repo_name).
Also renamed/moved to more sensible class a few static RepositoryName fields.
--
MOS_MIGRATED_REVID=128594419
|
|
|
|
|
|
|
| |
the transitive closure instead of having a global environment in the configuration.
--
MOS_MIGRATED_REVID=128559756
|
|
|
|
|
|
|
| |
purposes of license checking instead of having a bespoke method in BuildConfiguration.Fragment and encoding knowledge about static linking in buildtool/ .
--
MOS_MIGRATED_REVID=128557444
|
|
|
|
|
|
|
| |
infrastructure to allow other artifact categories (such as debug symbols or compiler outputs) to be defined in other changes.
--
MOS_MIGRATED_REVID=128495797
|
|
|
|
|
|
|
|
|
| |
Previously we used labels in each configuration fragment that then got added to every test action. Instead, we now have a filegroup under //tools/test for coverage files that truly need to be on the inputs of every test action and collect language-specific support files in InstrumentedFilesProvider.
This makes configuration creation simpler and makes it possible to turn --crosstool_top into something else other than a filegroup (previously, it was that filegroup that got added to every test action)
--
MOS_MIGRATED_REVID=126170241
|
|
|
|
|
|
|
| |
This is to simplify the contract of BuildConfiguration.Fragment, thus making it simpler to create BuildConfigurations without unnecessary fragments and eventually create configuration fragments from Skylark.
--
MOS_MIGRATED_REVID=125137625
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
experimental support
for building objc code using the c++ crosstool. This will eventually replace the current module support in blaze.
Note: This required injecting a CppModuleMap into the cc logic. The reason that objc cannot rely on standard CppModuleMap creation logic is that there is different naming semantics for module maps between cpp and objc. In particular:
- In cc, module maps can be inputs to a compilation action. Thus, the module maps are given labels.
- In objc, if interoping with swift, module maps are explicitly referenced in swift code. Thus, their names cannot contain illegal characters for swift source. Those, some name mangling occurs to get rid of "//" and ":". To enforce that this does not cause problems with compilation actions, the CPP_MODULE_COMPILE action has been disabled for the objc CcLibraryHelper.SourceCategory
--
MOS_MIGRATED_REVID=124177067
|
|
|
|
|
|
|
|
| |
Before this patch we would store expanded transitive include files in
CcLinkParams.
--
MOS_MIGRATED_REVID=123103815
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=122824226
|
|
|
|
|
|
|
|
| |
The method will be removed in a subsequent change to facilitate reverting the
change in case it goes bad.
--
MOS_MIGRATED_REVID=120526894
|
|
|
|
|
|
|
|
|
|
|
| |
SkyFunction.
This removes one of the two reasons for the existence of BuildConfiguration#prepareToBuild() which makes implementing dynamic configurations impossible and also makes FDO support halfway sane; now FDO is exactly as ugly as remote repositories, that is to say, reasonably okay.
Ideally, we'd implement the zip extraction as an Action and make it a TreeArtifact, but support for TreeArtifacts is not mature yet enough, so it's not possible at the moment.
--
MOS_MIGRATED_REVID=119150223
|
|
|
|
|
|
|
|
|
|
|
| |
Also, don't require the :stl attribute to be defined by all rules that
use CcLibraryHelper.
This makes it possible for other languages to use CcLibraryHelper to
create a CppCompilationContext.
--
MOS_MIGRATED_REVID=112494452
|
|
|
|
|
|
|
| |
CppSemantics instead.
--
MOS_MIGRATED_REVID=111406721
|
|
|
|
|
|
|
| |
Reduces garbage.
--
MOS_MIGRATED_REVID=109914243
|
|
|
|
|
|
|
| |
This makes all tool dependencies be under @bazel_tools again (and not //tools)
--
MOS_MIGRATED_REVID=107482585
|