check tensorflow version in CMake - tensorflow

I'm trying to check the TensorFlow (built from source) version in CMake.
If TensorFlow is built from source, there's a include ("eager", c_api.h, c_api_experimental.h, LICENSE) folder, and a lib (libtensorflow.so, libtensorflow_framwork.so) folder.
I tried find_package because of PACKAGE_FIND_VERSION variable. Although TensorFlow_FOUND variable was set, PACKAGE variable was not set. Maybe there needs something like .version file.
The reason I'm trying to do this is for a version check. My program needs tensorflow 1.10. If there is pre-built tensorflow already in user(/usr/include, /usr/lib), it should check version if it is 1.10.
Is there any good method for doing this?

Related

Disable mkl inside eigen

System information
OS Platform and Distribution : Debian GNU/Linux 10
TensorFlow installed from (source or binary): Source
TensorFlow version:latest
Python version:3.7.3
Installed using virtualenv? pip? conda?: virtualenv
Bazel version (if compiling from source):3.3.0
GCC/Compiler version (if compiling from source): gcc 8.3
I did NOT use the --config=mkl flag while building
The image is a call graph of 1024X1024 Matmul done 100 times, if you look carefully mkldnn_sgemm is called internally by Eigen, this is what I want to disable.
After some amount of reading I found out that MKL can be called internally by Eigen and after reading the Bazel documentation and seeing how TensorFlow is strucured.I want to disable mkl/mkl_dnn completely if eigen is to be used.
The Eigen build files loads the ifmkl symbol from the mkl directory.
My next step was to look at the if_mkl function inside the build_defs.bzl
I changed the includes attribute in the cclibrary rule in the BUILD file of eigen to ["//conditions:default"] and tried building it again
which game me an error saying ModuleNotFoundError: No module named 'portpicker'
So pip installed portpicker pip install portpicker
And the build completed sucessfully after I did this, but the profile literally shows no difference mkldnn_sgemm is still bieng called the same number of time by eigen internally.
NOTE: The Ultimate aim is to disable mkldnn which is bieng called from inside eigen

Statically link custom op from .a file in tensorflow serving

I have a custom op implemented CUDA and built using Makefile like this hdrnet. I can build .so and import in tensorflow. For tf-serving statically linking .a file is required but all tutorials reference bazel build process for custom op instead of directly linking compiled op from .a file.
Do I have to write build process as referenced by examples or I can build tf-serving with .so/.a files directly?
I ended up compile tensorflow-serving from source with op-linked in. Tensorflow tutorials are not complete for this and additional dependency was missing which I resolved in this issue issue.

How to force tensorflow to use a custom version of Eigen?

I am compiling Tensorflow 1.5, and I want to force bazel to include a custom version of the eigen header files, which are at:
usr/local/lib/python2.7/dist-packages/...
Conversely, whenever I try to compile (even after a bazel clean --expunge) tensorflow uses different files, which are copied during the build procedure at:
/root/.cache/bazel/_bazel_root/
Is there any way to force tensorflow to use different files?
You can change the tf_http_archive rule for eigen_archive (you must not change the name) in tensorflow/workspace.bzl to new_local_repository and use Tensorflow's eigen BUILD file (//third_party:eigen.BUILD).

Integrating tensorflow in a larger C++ project -- Library conflicts

Objective: Integrate tensorflow into a larger project.
Solution: 1) Integrate tensorflow into cmake by passing appropriate arguments to bazel and get a working build.
2) Unzip the *.whl file to get the library and headers.
Problem: Tensorflow builds but has its own header files for protobufs and Eigen. My project also depends on these two libraries and the versions might mismatch. However, I can use the libraries that tensorflow fetches and replace the one we currently use. We currently build protobuf in our system.
Question: I can find the protobuf and Eigen header files used by tesorflow inside the whl files built, but I cannot find the .so files.
My understanding of bazel is low, but it might be that it is removing the .so files from the sandbox it uses, I am not sure.
What can I do to always fetch the lib and include folders for tensorflow dependencies that it dowloads. Namely, protobuf. Eigen is header only.
Tried already: search in ~/.cache/bazel/ directory.

Compiling againt another version of Eigen using CMake

Am using ubuntu 16 which seems automatically linking against Eigen version 3.2.92 located at /usr/include/Eigen3. I would like to link against version 3.2.0. Thus my questions is
How could I get Eigen version 3.2.0? It is not clear from Eigen website
What I did so far is just copying /usr/include/Eigen3 from an ubuntu 14 machine, since the latter automatically comes with version 3.2.0
How to link against it using CMake?
Tried
SET (EIGEN3_INCLUDE_DIR "/home/usr/mylib/eigen/eigen3/Eigen") but without success.
For info, am using ROS (Kinetic) catkin. It happens that catkin somehow forces the development packages to linking/compiling against packages installed by default (/usr/include/..)
Other versions of Eigen are available on the website or better, from the hg repo.
How is the EIGEN3_INCLUDE_DIR used in your cmake file? For example, in one of my projects, we have set(EIGEN_INCLUDE_DIR ${SOURCE_DIR}/Common). Note that it doesn't have the "3" (it's just a variable name) and that it doesn't include the last "/Eigen" in the path.
First of all, Eigen is a header-only library, so you are not linking against it :-) Instead you want to use specific header files.
For your own packages, you can use include_directories(SYSTEM ${EIGEN3_INCLUDE_DIR}, assuming you set EIGEN3_INCLUDE_DIR correspondingly to the version you want to use. Beware that if that version differs too much (e.g. 2.x vs 3.x) with versions used by interfaces (e.g. tf library?), this may cause some issues if datatypes changed. You also need to make sure that no other directive overwrites that - best to check the parameters to g++ for that.