aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/cpp/CppHelper.java
Commit message (Collapse)AuthorAge
* Add no_stripping feature to MSVC CROSSTOOLGravatar Yun Peng2017-08-04
| | | | | | | | | | | | 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
* Use @CompileTimeConstant on SpawnAction.Builder#setProgressMessage.Gravatar tomlu2017-08-04
| | | | | | | | | 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
* Use feature configuration to construct command line for 'strip' actionGravatar hlopko2017-08-03
| | | | | | | | | | 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
* Compute progress message lazily in spawn action.Gravatar tomlu2017-08-03
| | | | | | | | | | 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
* Assert that declared providers are not TransitiveInfoProviders.Gravatar dslomov2017-07-28
| | | | | | | Also fix the remaining violations. RELNOTES: None. PiperOrigin-RevId: 163391215
* Use FeatureConfiguration to compute value of CC_FLAGS make variableGravatar hlopko2017-05-26
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Extract :cc_toolchain as constantGravatar hlopko2017-05-22
| | | | | | | | And while at it cleanup all the calls of CppHelper.getToolchain and CppHelper.getFdoSupport. RELNOTES: None. PiperOrigin-RevId: 156716291
* Automated g4 rollback of commit 6879d7ceff0e118fdecb0cabe5134979030b7cb8.Gravatar Googler2017-05-11
| | | | | | | | | | | | | | | | | | | *** 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
* Automated g4 rollback of commit cbbb423663b154d82e3dfa5e9a56839583987999.Gravatar Googler2017-05-10
| | | | | | | | | | | *** 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
* RELNOTES: Effectively remove sysroot from CppConfiguration and allow it to ↵Gravatar Googler2017-05-09
| | | | | | use select statements. PiperOrigin-RevId: 155480011
* Automated g4 rollback of commit 7beadb7277453efec7e12b925005e7f0e003b592.Gravatar nharmata2017-05-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | *** 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
* Automated g4 rollback of commit 38b835097f9ae9a6062172b8a33ec2e2d1edde20.Gravatar dmarting2017-05-02
| | | | | | | | | | | | | | | | | | | *** 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
* Only allocate some formerly frequently allocated PathFragment objects once.Gravatar nharmata2017-05-02
| | | | | | This reduces both gc churn and retained memory usage. PiperOrigin-RevId: 154718782
* Refactor all ctor callsites of PathFragment to instead call a static ↵Gravatar nharmata2017-04-05
| | | | | | | | | | | | '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
* Add an optional coverage_files argument to cc_toolchainGravatar Googler2017-03-22
| | | | | | | | | | | | 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
* apple_binary scopes link artifacts using child configuration for ↵Gravatar Cal Peyser2017-03-14
| | | | | | | | --experimental_objc_crosstool=all -- PiperOrigin-RevId: 150066766 MOS_MIGRATED_REVID=150066766
* Crosstool compilation support for J2ObjcAspect.Gravatar Rumou Duan2017-02-22
| | | | | | | | 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
* Error out when the STL label points to an undefined target when merging STLGravatar Luis Fernando Pino Duque2017-02-22
| | | | | | | | and toolchain contexts. -- PiperOrigin-RevId: 148104218 MOS_MIGRATED_REVID=148104218
* Rollback of commit 4b73e972d909bcd533f2f9940f95a00b9b73bdde.Gravatar Dmitry Lomov2017-02-17
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Roll forward execroot changeGravatar Kristina Chodorow2017-02-16
| | | | | | | | | | | | | | | | | 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
* CrosstoolCompilationSupport can be used for multi-arch binaries by allowing ↵Gravatar Cal Peyser2017-02-15
| | | | | | | | | | | | | | | | | 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
* Stop retrieving FdoSupport statically from hard-coded attribute ↵Gravatar Rumou Duan2017-02-14
| | | | | | | | | | ":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
* Introduce CppCompileActionTemplate, which expands into a list of ↵Gravatar Rumou Duan2017-02-10
| | | | | | | | CppCompileActions that to be executed at execution time. -- PiperOrigin-RevId: 147163077 MOS_MIGRATED_REVID=147163077
* Stop retrieving CcToolChainProvider statically from hard-coded attribute ↵Gravatar Rumou Duan2017-02-08
| | | | | | | | | | ":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
* Add a flag that alters the behavior of the parse_headers feature. With theGravatar Googler2017-01-27
| | | | | | | | | | | | | 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
* Initial commit of cc_proto_library.Gravatar Carmi Grushko2016-12-01
| | | | | | | RELNOTES: cc_proto_library generates C++ code from proto_library rules. -- MOS_MIGRATED_REVID=140680034
* Rollback of commit 82d43279f93d95e4c41b4bc598a3cc05ddd1ae1a.Gravatar Laszlo Csomor2016-09-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | *** 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
* Change execution root for external repositories to be ../repoGravatar Kristina Chodorow2016-09-20
| | | | | | | | | | | | | | | | | | | | | | | 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
* Make cc_toolchain not croak if something that is not a shared library is ↵Gravatar Lukacs Berki2016-09-12
| | | | | | | mentioned in the dynamic_runtime_libs attribute. -- MOS_MIGRATED_REVID=132676097
* Make the code that is using execRoot paths use execRoot pathsGravatar Kristina Chodorow2016-09-09
| | | | | | | | | | | 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
* Instead of filtering for dynamic libraries when creating solib symlinks, ↵Gravatar Lukacs Berki2016-08-22
| | | | | | | | | 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
* Record the category of the artifact to be linked in LinkerInput.Gravatar Lukacs Berki2016-08-12
| | | | | | | | | 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
* Add the repository name as a parameter to the output path functionsGravatar Kristina Chodorow2016-08-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Refactor C++ rules so that CcLinkingOutputs.libraryIdentifierOf() gets ↵Gravatar Lukacs Berki2016-08-09
| | | | | | | 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
* Avoid hard-coded extensions for compilation outputs.Gravatar Lukacs Berki2016-08-05
| | | | | | | | | 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
* Rename some PackageId and RepositoryName fields/methods in prep for deep ↵Gravatar Kristina Chodorow2016-07-28
| | | | | | | | | | | | | 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
* Pass the coverage environment into tests using a nested set collected from ↵Gravatar Lukacs Berki2016-07-27
| | | | | | | the transitive closure instead of having a global environment in the configuration. -- MOS_MIGRATED_REVID=128559756
* Use a marker provider to determine of a rule is linked statically for the ↵Gravatar Lukacs Berki2016-07-27
| | | | | | | 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
* Linker outputs can optionally be configured from the CROSSTOOL. Introduces ↵Gravatar Cal Peyser2016-07-27
| | | | | | | infrastructure to allow other artifact categories (such as debug symbols or compiler outputs) to be defined in other changes. -- MOS_MIGRATED_REVID=128495797
* Refactor how coverage support files get to test actions.Gravatar Lukacs Berki2016-06-29
| | | | | | | | | 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
* Remove BuildConfiguration.addRoots() and the pregrepped includes directory.Gravatar Lukacs Berki2016-06-17
| | | | | | | 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
* Add module map support to ExperimentalObjcLibrary, which contains ↵Gravatar Cal Peyser2016-06-07
| | | | | | | | | | | | | | 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
* Make linkstamp info use NestedSet.Gravatar Manuel Klimek2016-05-25
| | | | | | | | Before this patch we would store expanded transitive include files in CcLinkParams. -- MOS_MIGRATED_REVID=123103815
* Change some weird formating.Gravatar Cal Peyser2016-05-20
| | | | | -- MOS_MIGRATED_REVID=122824226
* Remove all internal calls to FileProvider.getLabel.Gravatar Ulf Adams2016-04-22
| | | | | | | | The method will be removed in a subsequent change to facilitate reverting the change in case it goes bad. -- MOS_MIGRATED_REVID=120526894
* Move FDO support to the analysis phase by wrapping FdoSupport in its own ↵Gravatar Lukacs Berki2016-04-07
| | | | | | | | | | | 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
* Blaze CcLibraryHelper: make creating a CppCompilationContext publicGravatar Googler2016-01-20
| | | | | | | | | | | 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
* Remove Constants.ALLOW_CC_INCLUDE_SCANNING and handle the logic in ↵Gravatar Philipp Wollermann2016-01-07
| | | | | | | CppSemantics instead. -- MOS_MIGRATED_REVID=111406721
* Use Bazel Preconditions variant which avoids varargs array creationGravatar Mark Schaller2015-12-10
| | | | | | | Reduces garbage. -- MOS_MIGRATED_REVID=109914243
* Make STL work even when not in the main repository.Gravatar Lukacs Berki2015-11-11
| | | | | | | This makes all tool dependencies be under @bazel_tools again (and not //tools) -- MOS_MIGRATED_REVID=107482585
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-31 01:37:59 +0000