[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Tensorflow embedded script usage

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:
(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
(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.

Principal hats:  Linaro, Debian, Wookware, ARM

Attachment: signature.asc
Description: PGP signature

Reply to: