| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
Prepare pkg.bzl to be compliant with upcoming Skylark changes. With this change,
one can use pkg_tar even if using --all_incompatible_changes.
Change-Id: Iff0ed50bda1f93d9f606b783295b049bdf15d242
PiperOrigin-RevId: 190443156
|
|
|
|
|
|
|
| |
at end of basename.
RELNOTES: None
PiperOrigin-RevId: 190115344
|
|
|
|
|
|
| |
Fixes bazelbuild/bazel#4899
PiperOrigin-RevId: 190083263
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`setup_vc_env_vars` runs vcvarsall.bat to setup environment varibles for Visuall C++ build tools.
It returns the values of PATH, LIB, INCLUDE and WINDOWSSDKDIR.
Expose this function so that users can use
load("@bazel_tools/tools/cpp:windows_cc_configure.bzl", "setup_vc_env_vars")
to access this function.
Fixed https://github.com/bazelbuild/bazel/issues/4542
RELNOTES[NEW]:
Now you can access three functions in windows_cc_configure.bzl by:
load("@bazel_tools/tools/cpp:windows_cc_configure.bzl", "<function_name>")
1. find_vc_path(repository_ctx): Detect the VC installation path on your machine, respect BAZEL_VC first, return None if VC not found.
2. setup_vc_env_vars(repository_ctx, vc_path): Get PATH, LIB, INCLUDE, WINDOWSSDKDIR env vars set by VCVARSALL.bat, return None if VCVARSALL.bat not found.
3. find_msvc_tool(repository_ctx, vc_path, tool): Find a certain VC build tool (eg. cl.exe, lib.exe, link.exe), return None if tool not found.
Change-Id: Iec5770165aaa4766470bb3b4d818a2cf90678586
Closes #4892.
Change-Id: Iec5770165aaa4766470bb3b4d818a2cf90678586
PiperOrigin-RevId: 190039950
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks on windows: https://www.google.com/url?sa=D&q=https%3A%2F%2Fbuildkite.com%2Fbazel%2Fgoogle-bazel-presubmit%2Fbuilds%2F624%234a68440b-948b-437b-a633-4f0595721bab
*** Original change description ***
Automated rollback of commit 3c5a1098af0c5ae80d4e3b1fc52dd1fef6027d43.
*** Reason for rollback ***
Breaks bazel ci: https://github.com/bazelbuild/bazel/issues/4894#event-1533040075
*** Original change description ***
Add crosstool_lib.bzl and crosstool_utils.bzl
These will be used to rewrite current crosstool autoconfiguration into
action_configs and features.
RELNOTES: None.
PiperOrigin-RevId: 189906675
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks bazel ci: https://github.com/bazelbuild/bazel/issues/4894#event-1533040075
*** Original change description ***
Add crosstool_lib.bzl and crosstool_utils.bzl
These will be used to rewrite current crosstool autoconfiguration into
action_configs and features.
RELNOTES: None.
PiperOrigin-RevId: 189901308
|
|
|
|
|
|
|
|
| |
These will be used to rewrite current crosstool autoconfiguration into
action_configs and features.
RELNOTES: None.
PiperOrigin-RevId: 189888171
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
breaks building //src:bazel
*** Original change description ***
runfiles,C++: move to //tools/cpp/runfiles
Move the C++ runfiles library to the location of
the rest of the C++ tools.
Also change the C++ namespace to reflect the
directory hierarchy.
We have not yet announced nor released the C++
runfiles library so these refactorings are fine.
See https://github.com/bazelbuild/bazel/issues/4460
Closes #4873.
PiperOrigin-RevId: 189883066
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the C++ runfiles library to the location of
the rest of the C++ tools.
Also change the C++ namespace to reflect the
directory hierarchy.
We have not yet announced nor released the C++
runfiles library so these refactorings are fine.
See https://github.com/bazelbuild/bazel/issues/4460
Closes #4873.
Change-Id: I1732ef1eaff880cae05b7d218a3b1c0461a6b029
PiperOrigin-RevId: 189874201
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new package that'll host the Bash runfiles
library.
See https://github.com/bazelbuild/bazel/issues/4460
Closes #4882.
PiperOrigin-RevId: 189871255
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Temporarily remove the Python runfiles library
from @bazel_tools and so prevent releasing it in
Bazel 0.12.0.
Motivation: https://github.com/bazelbuild/bazel/issues/4878
Fixing that bug *after* the python library is in
release Bazel would be harder because users would
need to update their code and BUILD files.
Fixing that bug before the library is released is
a lot easier because nobody depends on it yet, and
we can release the library when it's in the right
place.
Closes #4879.
Change-Id: I8adc219410571f9e2a4c8060f5b3239b957fbd5f
PiperOrigin-RevId: 189744985
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 189593708
|
|
|
|
|
|
| |
already been migrated to github.com/bazelbuild/rules_apple.
PiperOrigin-RevId: 189245171
|
|
|
|
| |
PiperOrigin-RevId: 189023695
|
|
|
|
|
|
|
|
|
|
|
| |
Bazel now only reports VC detection error when users actually try to build C++ targets.
Fixed https://github.com/bazelbuild/bazel/issues/4813
Closes #4818.
Change-Id: I224f54eae9fc9ff87bc13059609dccac17804210
PiperOrigin-RevId: 189009905
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Added the "rpm_nvra" output which follows the recommended package naming convention of *Name-Version-Release.Arch.rpm* (NVRA). See http://ftp.rpm.org/max-rpm/ch-rpm-file-format.html
2. Expose "release" and "release_file" parameters to support the NVRA naming convention
3. Remove the mandatory constraint on version parameters (version or version_file): I want to auto-generate my SPEC file outside of the pkg_rpm rule, and I don't want pkg_rpm altering the file.
Closes #4732.
PiperOrigin-RevId: 188744806
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #4810, invalidates #4782, and extends #4747.
Change-Id: I19426bb30a151358875e9bae0e0c1d92b3818432
Closes #4816.
Change-Id: I5d92cec994103e2136c5ed279780f321a42d1bdd
PiperOrigin-RevId: 188722982
|
|
|
|
| |
PiperOrigin-RevId: 188375134
|
|
|
|
| |
PiperOrigin-RevId: 188182739
|
|
|
|
|
|
|
| |
files for include statments. This binary is currently only used for an internal feature - but that feature may be supported externally eventually.
RELNOTES: None
PiperOrigin-RevId: 188173513
|
|
|
|
|
|
|
|
| |
Fixes #4738
Closes #4764.
PiperOrigin-RevId: 188167356
|
|
|
|
| |
PiperOrigin-RevId: 188013147
|
|
|
|
| |
PiperOrigin-RevId: 187988936
|
|
|
|
| |
PiperOrigin-RevId: 187986062
|
|
|
|
|
|
|
|
| |
Previously, there was a risk of filename collisions, since all data files were flattened into the BUILD directory.
Closes #4747.
PiperOrigin-RevId: 187870196
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 187849221
|
|
|
|
|
|
|
|
| |
cc-compiler-darwin depends on osx_wrapper and we should refer to it in dependencies. Otherwise only standalone builds will work.
Closes #3929.
PiperOrigin-RevId: 187846122
|
|
|
|
|
|
|
|
| |
The previous comment referred to the option `/EHa`, but `/EHsc` is the option to only catch C++ standards (which seems to be what we want, according to this doc: https://msdn.microsoft.com/en-us/library/1deeycx5.aspx)
Closes #4739.
PiperOrigin-RevId: 187593737
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previous behaviour:
* The CopyAndRewrite function would raise a write permission denied error on the output file, which had permissions 0555, when the input SPEC file was auto-generated.
Current behaviour:
* Do not copy the input SPEC file (auto-generated or otherwise) to the destination in the temporary working directory since the CopyAndRewrite function will generate the output file regardless. This allows the package to support static or auto-generated SPEC files.
Closes #4716.
PiperOrigin-RevId: 187511568
|
|
|
|
|
|
|
|
| |
The changelog is not used by make_rpm.py, and I don't have a need for it since I auto-generate the SPEC file, which includes a "%changelog" section, prior to invoking the pkg_rpm rule.
Closes #4717.
PiperOrigin-RevId: 187494400
|
|
|
|
|
|
|
|
|
|
| |
By simply sharing the utility function. In this way, we get
feature parity between git_repository and http_archive.
Fixes #4676.
Change-Id: I99b300e42b2f267d8d04fd965f09c24f3ae54f10
PiperOrigin-RevId: 187450644
|
|
|
|
|
|
|
|
| |
...thus avoiding having them several times for the various repository
rules, each with slightly different behavior and bugs.
Change-Id: I6cec0c0dd0901453458903e226ceb2098a93cdd8
PiperOrigin-RevId: 187306904
|
|
|
|
|
|
|
| |
filenames.
RELNOTES: None
PiperOrigin-RevId: 187252891
|
|
|
|
|
|
|
|
|
|
|
| |
Use the path that contains a temporary junction in
the scope of the `with` statement that manages the
lifetime of the temp junction.
This allows compiling
//examples/android/java/bazel:hello_world again.
PiperOrigin-RevId: 187188442
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
autogenerated cc toolchain
Relevant to #4031, fixes #4524.
Does not affect the osx + xcode toolchain that supports both C++ and ObjC!
RELNOTES: BAZEL_LINKOPTS is now consulted when autoconfiguring c++ toolchain
Now linker flags for the autogenerated C++ toolchain can be controlled by
BAZEL_LINKOPTS environment variable (using colon as a flag separator):
BAZEL_LINKOPTS=-lc++ bazel build //...
The default value is "-lstdc++:-lm".
PiperOrigin-RevId: 187173297
|
|
|
|
|
|
|
|
| |
This function allows us to split strings coming from env variables into lists
while respecting %-escaping.
RELNOTES: None.
PiperOrigin-RevId: 187166226
|
|
|
|
|
|
|
|
|
|
| |
The tags attribute is already implicit on every rule.
This also will help power https://github.com/bazelbuild/bazel/issues/1372#issuecomment-364001669
RELNOTES[NEW]: Pass `tags` from `java_import_external` rule to the generated `java_import` rule.
PiperOrigin-RevId: 187019602
|
|
|
|
|
|
| |
so it works outside of @bazel_tools//tools/jdk
PiperOrigin-RevId: 187011676
|
|
|
|
|
|
| |
Fixes 4480.
RELNOTES: None.
PiperOrigin-RevId: 186774229
|
|
|
|
|
| |
Change-Id: Idb0c9fe770cd73c2760bee92997063c4c9b2e94e
PiperOrigin-RevId: 186768436
|
|
|
|
|
|
|
|
|
|
|
| |
When --run_under is used, the run-under wrapper will be injected in front of the normal test command line. So, it's incorrect to use the beginning of the command line to infer the test name. However, we can always get the underlying test executable with the TEST_BINARY environmental variable.
Rename TEST_NAME to EXE to avoid future confusion.
Fixes https://github.com/bazelbuild/bazel/issues/4588.
Change-Id: I6fd05cca5e5441c13ee16290c4028ec84adec983
PiperOrigin-RevId: 186590311
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 186511953
|
|
|
|
|
|
|
|
|
| |
to check the completeness of the deps of aar_import targets.
Followup cl of unknown commit
RELNOTES: None.
PiperOrigin-RevId: 186503514
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/3904ac33a983fd8faebba1b52bcac5a3ff942029 (https://github.com/bazelbuild/bazel/commit/3904ac33a983fd8faebba1b52bcac5a3ff942029). Fix #4625 by running the test process in a sub-shell.
Apparently, nested background processes interfere with SIGINT handling in bash. I don't 100% understand why and how, but I do have a small bash script that demonstrates the problem: script A that spawns a background process, sends it a SIGINT, and verifies it was received. The script works, *unless* run in the background by a process B; this extra layer of backgrounding cause process A's logic to stop working. See experimental/users/olaola/shell/ for examples. See also https://stackoverflow.com/questions/48847722/nested-background-processes-and-sigint-handling
*** Original change description ***
Fixing test-setup.sh occasionally missing stdout/stderr, on systems where "tail --pid" is supported.
The solutions aren't mine, the new test was taken from Ola's unknown commit and the way to avoid race condition courtesy of sethkoehler@
Mitigates #4608 for compatible Linux systems.
TESTED=presubmits, manual shell tests on new bazel
RELNOTES: None
PiperOrigin-RevId: 186312008
|
|
|
|
|
|
|
|
|
| |
Since the http_archive inherits the native download_and_extract function,
the support of plain tar archives introduced in 4c8fa1bab507fa7f0a1cbeac0724751d9b574f89
applies here as well. Fix the doc strings accordingly.
Change-Id: Ica4037215abf7498c3a8ec9f21ac32b2e59e8966
PiperOrigin-RevId: 186293816
|
|
|
|
|
|
|
|
|
|
|
| |
...to ease transition from the native http_archive rule. In this way,
switching from the native http_archive rule to the skylark one literally
is only adding
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
Change-Id: I0d3a16ad9ab046b975ea64c97dd201e7a9d70a6a
PiperOrigin-RevId: 186285020
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With https://github.com/bazelbuild/bazel/commit/e99279bcce475249e58543a5330fa35e59acd7e8 we started passing -no-canonical-prefixes to clang, but that
causes inconsistent directories used in .d files and system include
directories. The solution is to pass -no-canonical-prefixes also when asking
clang for system include directories.
Interestingly, clang in debian breaks when called like:
`clang -E -xc++ - -v -no-canonical-prefixes`
we have to pass absolute path to the binary like:
`/usr/bin/clang -E -xc++ - -v -no-canonical-prefixes`
then it works.
Fixes #4572.
RELNOTES: None.
PiperOrigin-RevId: 186210671
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rolling back after having come up with a more principled solution in b/73047818 that will add a more generic attribute called additional_linker_inputs so that users can depend on any file of any type and reference it from linkopts.
*** Original change description ***
C++: Allows adding linkopts through file.
The file can be generated during execution by a different rule.
RELNOTES:none
PiperOrigin-RevId: 185977745
|