Repositories depending on TensorFlow should use the content of the WORKSPACE file to initialize TensorFlow and its dependencies. This will make it much less likely for us to break dependent projects when we add/change TensorFlow's dependencies.
PiperOrigin-RevId: 345391447
Change-Id: Ia5f66a341247d0da491e40aee39f460ac10d5c9b
- Add libgpr
Newer grpc-1.28 has a libgpr.so that is also needed during link time
so add it to the linkopts
- Add starlark files
Several starlark files are load()'d from the GRPC repo, vendor them
or add stubs as appropriate when using the system version of grpc.
- grpc WORKSPACE deps
Several deps were loaded in WORKSPACE that were needed by grpc, they
are not needed when building against the system but are difficult to
stub out causing the build to fail.
grpc_extra_deps.bzl is provided to load all the requirements, so use
that from WORKSPACE instead of directly loading each individually.
This is also more maintainable going forward since there is less to
keep in sync in TF's WORKSPACE file.
Signed-off-by: Jason Zaman <jason@perfinion.com>
Add two repository rules:
- @local_execution_config_platform: local platform to allow selecting locally
executed tools on
- @local_execution_config_python: python configured for execution...
PiperOrigin-RevId: 307862682
Change-Id: Ie0320f2f137a40b418632989981c9dc072ef80e6
- @local_execution_config_platform: local platform to allow selecting locally
executed tools on
- @local_execution_config_python: python configured for execution on the local
machine during otherwise remote builds
Mark rules that are required to run locally to require our local platform.
This allows pyth...
PiperOrigin-RevId: 307771596
Change-Id: If1f0013ec88a35d507b2b622894208aab2416fe5
- @local_execution_config_platform: local platform to allow selecting locally
executed tools on
- @local_execution_config_python: python configured for execution on the local
machine during otherwise remote builds
Mark rules that are required to run locally to require our local platform.
This allows python paths to differ between the remote docker image and local
machine.
For example, the local machine might have python 3.7 installed in
/usr/bin/python3, while the remote docker should use a python installed
in /usr/local/bin/python3.8.
PiperOrigin-RevId: 307585019
Change-Id: I29313121beb967b77ae123e7d1b614c688cb40ca
- @local_execution_config_platform: local platform to allow selecting locally
executed tools on
- @local_execution_config_python: python configured for execution on the local
machine during otherwise remote builds
Mark rules that are required to run locally to require our local platform.
This allows python paths to differ between the remote docker image and local
machine.
For example, the local machine might have python 3.7 installed in
/usr/bin/python3, while the remote docker should use a python installed
in /usr/local/bin/python3.8.
PiperOrigin-RevId: 307558811
Change-Id: I0dc2d877a7c26b294bf2b569b4f121cf6506e7fc
Fixes#33758
Downstream projects depending on TensorFlow: If bazel complains, please substitute `@zlib_archive` with `@zlib`, and `@grpc` with `@com_github_grpc_grpc` in WORKPLACE.
PiperOrigin-RevId: 295824868
Change-Id: If2259d59e9d82543369e5670916b1398374c9889
--python_path will be removed in future Bazel, we should switch to use python toolchain. But currently we want Bazel to always use the same python binary specified in configure.py regardless of what's specified in py_binary rule (PY2 or PY3). So we point both py2 and py3 runtime to the same PYTHON_BIN_PATH.
PiperOrigin-RevId: 273032026
The custom commit contains a fix to make protobuf.bzl compatible with Bazel 0.26 or later version.
Also fix WORKSPACE file to make sure tf_workspace() always takes priority over dependency definitions of other repositories.
PiperOrigin-RevId: 253970221
Also removed bazel-toolchain support for Bazel version prior to 0.19.0 and updated check_bazel_version_at_least in WORKSPACE file
To fix https://github.com/bazelbuild/bazel/issues/7113
PiperOrigin-RevId: 229392830
This makes this command succeed:
bazel build //tensorflow/tools/pip_package:build_pip_package --incompatible_disallow_data_transition
This is needed for a future change in Bazel.
Bazel-0.18.0 adds a try-import option that will non-fatally try and
import a file. Use this for the configure options so that .bazelrc does
not need to change. ./configure rewriting .bazelrc makes using the git
repo annoying because the file is changed.
The allowed bazel range is now 0.18.0-0.20.0 inclusive. The env var
TF_IGNORE_MAX_BAZEL_VERSION can be set to skip the max bazel version
check.
Also optionally import a /.bazelrc.user file that is gitignored so
user-specific options can go in there.
Fixes: https://github.com/tensorflow/tensorflow/issues/22762
Fixes: https://github.com/tensorflow/tensorflow/pull/22906
Signed-off-by: Jason Zaman <jason@perfinion.com>
