Hi Felix,
I already saw this patch on salsa. However, I don't think package maintainers should add new targets or change logic. Did you already try to get that into upstream tensorflow? Looks like you can use CMake to build a shared monolithic tflite library with cmake. But the name is different (libtensorflowlite_c.so) [1] Other components like libedgetpu (for coral) seem to attract tflite targets as well. But all that logic is baked in into bazel files, so you cannot easily say that your shared tflite lib should be used. Currently we just live with that situation. Is the cmake-generated library different from yours, or why did you choose bazel to build it? [1] https://www.tensorflow.org/lite/guide/build_cmake#build_tensorflow_lite_c_library
No, we haven't tried to get it upstreamed, the idea was more to get something working with Tensorflow Lite and try it as a build-dependency then see if people thought it would be OK to move forward.
This was a while ago when ArmNN was still using Tensorflow 2.3.1, the CMake flow was added in 2.4.
ArmNN is now using 2.5 Tensorflow with CMake as you mentioned so upgrading the version of the packaging would be good to allow that for Debian too.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
Thanks for the info, Francis. |