Avoid using `--enable_platform_specific_config` when cross-compiling for
iOS/Android, as this pulls in host build flags, which may not be
appropriate (e.g., when cross-compiling for Android on a Windows host).
Also fix an issue when building tensorflowlite_c for iOS.
Fixes#38525.
PiperOrigin-RevId: 311767770
Change-Id: I80b817fd89a6889dc78be50f1def8b899f091cb6
The local gen_build_info rule calls into find_cuda_config, which only works in the remote image.
This is additionally brittle: relying on TF_CUDA_VERSION being an action_env is poisoning our caches, and running find_cuda_conifg multiple times is bugprone.
I think the better way to do this is to put the information from the repo_rule into a file template as part of the repo rule configuration (cuda_configure.bzl). Then we can just include that file, instead of trying to do that as part of the action.
PiperOrigin-RevId: 311148754
Change-Id: I80daa8652a85b2a1897c15117e6422bfd21cee6a
Since this module now generates a dictionary to expose in tf.config, it
doesn't make much sense to store only certain values in the build_info
dictionary and others as module variables. This obsoletes a lot of code
in gen_build_info.py and I've removed it.
I also updated all the in-code references I've found to the build_info
module. I think this may break whomever used to be using the build_info
library, but since it wasn't part of the API, there was no guarantee
that it would continue to be available.
Ensure all TFLite binary targets have fully resolved symbols at link
time. Also enabling building of .dylib targets for iOS.
PiperOrigin-RevId: 308144394
Change-Id: I8cea13a8721447e27baff99c8dcf2166d9ed1c3c
Ensure all TFLite binary targets have fully resolved symbols at link
time. Also enabling building of .dylib targets for iOS.
PiperOrigin-RevId: 307902313
Change-Id: I6ec48fbd7e8f51b8b786eba9d13118cb51638fde
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
The tfrt_enabled target duplication logic was initially added to cuda_py_test,
but there are tests that directly use tf_py_test, so add to tf_py_test instead.
PiperOrigin-RevId: 307719942
Change-Id: I90bb1009c5cadf1a5a0a3d036a3a174d31b84eac
- @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
The API accepts TFE_RegisterCustomDevice arguments as PyCapsules, so each custom device will need some method to create those. Presumably most custom devices will end up wrapping the PyCapsule creation+registration rather than exposing it to the user.
No public API yet, but this is roughly what I have in mind at the moment.
This only works with --config=monolithic or when the custom device registration is bundled with pywrap_tensorflow.so right now since that has its own copy of the C API. Something like this could work if we switched pywrap_tensorflow.so to instead rely on libtensorflow.so for the C API, then custom device extensions could link against that.
PiperOrigin-RevId: 305762978
Change-Id: I4d2d9bd9c01ba22391e138244a3948bae8963c5c
Also create a similar tf_grpc_dependency function for the third_party/tensorflow:grpc dependency.
PiperOrigin-RevId: 304494463
Change-Id: I7a8684a5283ce10d7d586cfe0fb0b4a6506a6866
These tests are marked as manual, so they will not run automatically in testing.
This is in consideration of test timing and resource utilization, but these tests are expected to be passing.
PiperOrigin-RevId: 301185842
Change-Id: I7967440ffa8cd149d43a702ab11c5a3f19cc98a4
Also modified pybind_extension to accept additional symbols to export.
PiperOrigin-RevId: 300483745
Change-Id: I7168f25688e52e84679732531c7cb22befe29d85
(bugfix) We thought the previous CL ensured this, but looks like there
were some missing pieces in the genrule & MANIFEST files.
PiperOrigin-RevId: 298715688
Change-Id: Ib0a20cb10fb3b36686419b02c2f8ab6afd438d57
This target and its src/hdr filegroups can be used as a "single source of truth"
to identify the .cc and .h files necessary to build the XLA AOT runtime.
We export these .cc files as part of the tf pip package so that users
who use e.g. saved_model_cli aot compilation know which additional files are
required to build a library or binary around their object file.
As a followup we'll provide a cmake file that builds these to .o and includes
the correct dependencies on absl and nsync cmake files.
Additionally update the version of abseil so we can get the new cord dependency.
PiperOrigin-RevId: 298391947
Change-Id: I70cab3b5e8de48bcb42c5ec329dd0adf9303136a
This target and its src/hdr filegroups can be used as a "single source of truth"
to identify the .cc and .h files necessary to build the XLA AOT runtime.
We export these .cc files as part of the tf pip package so that users
who use e.g. saved_model_cli aot compilation know which additional files are
required to build a library or binary around their object file.
As a followup we'll provide a cmake file that builds these to .o and includes
the correct dependencies on absl and nsync cmake files.
Additionally update the version of abseil so we can get the new cord dependency.
PiperOrigin-RevId: 297986445
Change-Id: Ia5a4d9a6b0673c9edcd5d889d888235ca5f5453b
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
optimization which causes pywrap_tensorflow_internal.so not to be linked to
libtensorflow_framework.so. To prevent this behavior we have added a dependency
on a cc_import target in tf_cc_shared_object.
PiperOrigin-RevId: 294952433
Change-Id: Id49e7abb1171fbe5c00c0a6389ef57d9bb5713b7
