On 2021-04-27 04:34 +0000, M. Zhou wrote: > Hi Wookey, > > On Tue, 2021-04-27 at 03:01 +0100, Wookey wrote: > > > > One bit is confusing me, and I presume you wrote it so I'm wondering > > how it is intended to work: there is a debian/embedded.sh script > > which > > unpacks tarballs in debian/embedded dir into external/$foo > > I guess you may have contacted the wrong maintainer about this script. > Git blame could tell you that it's some kind of leftover from my old > packaging works (non-bazel-based). Aha. Sorry Michael, that was just a 'you touched it last' assumption :-) I didn't think of 'git blame'. Anyway, thnks for clarifying. That makes sense now. > I did not purge debian/embedded > and the corresponding directory because in the past: > > 1. tensorflow requires abseil-cpp to build. However the API/ABI of > abseil-cpp is too volatile to be appropriate for debian packaging. > 2. tensorflow (some old version) requires a specific snapshot of eigen3 > that is newer than libeigen3-dev provided by debian to build > successfully. Unstable has 3.3.9. The version in debian/embedded is clearly newer code (although oddly from a mercurial repo where the older one is git) but I can't find a version number anywhere in the codebase (apparently not big on versioning, these people), and the bazel system of grabbing a tarball with a specific SHA doesn't tell you anything about required versions either. So I guess I just have to try 3.3.9 and see if it works. It looks like the build is not yet using the system library. > I don't know if the current bazel-based packaging process is going > to use the two embeded sources -- please remove them if not. I'm > leaving the question to crusoe. The mechanism seems useful to have, if only for testing. > > I'm also a bit confused about the difference between external/ and > > third-party/ dirs. I can't see anything that causes the build to look > > in the 'external' dir. But my understanding of bazel is very weak so > > I > > could easily be confused. > > I have no idea about the external/ directory. That's where embedded.sh unpacks things to: https://salsa.debian.org/deeplearning-team/tensorflow/-/blob/master/debian/embedded.sh (and then it could copy in/overwrite-with the updates from third_party/ but currently doesn't) > > It seems that currently the tensorflow_framework library (target > > //tensorflow:tensorflow_framework ) builds, and so does the c++ > > library (target //tensorflow:tensorflow_cc), but the c library does > > not (complains of missing com_github_grpc_grpc despite libgrpc-dev > > and > > libgrpc++-dev being installed). > > I'm not sure whether this is related, but I think an empty bazel > BUILD file is not helpful at grabbing solid dependencies: > https://salsa.debian.org/deeplearning-team/tensorflow/-/blob/master/third_party/grpc/BUILD Yeah, I saw that was empty. I thought that setting --repo_env=TF_SYSTEM_LIBS=nsync,curl,double_conversion,snappy,gif,zlib,com_google_protobuf,com_github_grpc_grpc (and patching WORKSPACE) made the contents of that dir irrelevant. Odd that this works OK for building libtensorflow_cc, but not ibtensorflow. Will investigate further. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: PGP signature