Makefile provided under makefile_build obsolete

[benallard]

Description

I tried to build the library locally for me, and I tried the third option would be the easiest, unfortunately, the Makefile reference source from the tensor flow repository that don't exists anymore for years (tensorflow/lite/c/common.c).

Hence the build is not even starting.

Click to expand!

Issue Type

Build/Install

Operating System

Linux

Coral Device

USB Accelerator

Other Devices

No response

Programming Language

C++

Relevant Log Output

make: *** No rule to make target '/home/ben/aur/libedgetpu-git/src/tensorflow-2.16.1/tensorflow/lite/c/common.c', needed by '/home/ben/aur/libedgetpu-git/src/libedgetpu/makefile_build/../out//home/ben/aur/libedgetpu-git/src/tensorflow-2.16.1/tensorflow/lite/c/common.o'.  Stop.

[feranick]

Which system are you trying to compile it for? Linux, Windows, MacOS? The repo has been updated to support FT 2.16.1, although using bazel is easier.

[benallard]

I'm trying to build it for linux (Arch), and the huge amount of dependencies required by bezel holds me back.

If you are not willing to update the Makefile, I suggest you should better delete it. Leaving it there in a state where it's not even able to find the files it's willing to compile is very frustrating.

[feranick]

FIrst: while I am a simple user like you, I actually modernize most of the infrastructure to build libedgetpu with modern versions of TF, submitted PRs and luckily found a willing googler to help (Thanks @Namburger !!!). Yet, I don't have any "power" to remove a feature. This is to say that given the stale state of development, you will have to do the heavy lifting yourself, like I did, and modernize the makefile and possibly pass along that info so that it may be included. Arch Linux isn't a supported system, but that is a chance to make it so.

Second: I prefer the bazel route because it is the standard way TF is built. I am not sure where you are getting bazel, but as installed as a single exec sh file), there are no dependencies needed.

https://github.com/bazelbuild/bazel/releases/download/6.5.0/bazel-6.5.0-installer-linux-x86_64.sh

[mgomersbach]

@feranick obviously your work is very much appreciated, so thank you for that.

I do however feel @benallard 's pain, I use a different distribution, but probably experiencing the same problem as him.

It's the reproducability that holds us back; it's very easy to download a external binary from the internet "and use it to build it", the reality is however that at this point you "poison" your linux distribution, as the build systems that come with those distributions track files location and which package they belong to. This ensures a stable system, as these "manual hacks" don't go sour over time and everything is accounted for and rebuildable.

What we currently have for this project is the equivalent of "Here download this dll and put it in your system32" folder.
When put like that, it would seem outragious right? We know not to do things like this.

I hear you think "Why not extend your linux build system with bazel then?", bazel is extremely complicated. It's it is own entire environment, and does it offer anything other build systems do? No. Does google have a track record of maintaining their stuff so I don't this work for nothing? Also no.

That means that "clean" linux distros now need to implement a very complex, constantly moving, and ultimately futile target.
We have done it before, and we removed it from the package repository again because pampering to Bazel became a full time job.

When we see a makefile that has 2 lib dependencies and should prevent pulling bazel, that makes people like me and @benallard very excited, because it means we might actually enjoy this instead of hacking our system. (which is fine if you don't care about your distro or installation).

Obviously this also applies to TF, and it's the same reason that package has been removed from the Gentoo portage tree as well.
Thank to bazel it's simply a no-go, no matter how many users we make sad with this, it is _not _ worth it to compromise their machines.

The above is just some context about this issue, but no real addition/solution, sorry.

[feranick]

Thank you for such context, for which I am very aware of. I have nothing to add to what I said above. Context for context, here's some more.

This library has been basically discontinued by Google. This means that even for supported distros, you wouldn't be able to compile it, bazel or not. Note that Google still happily sells the edgetpu, in fact ASUS is in charge of business bulk sales and they are obnoxiously not aware that they are selling a brick that won't run ANYWHERE. Yet outdated binaries were available, but, correctly as you said, suboptimal in the linux spirit, and with the additional disadvantage of running with outdated versions of Python, TF, etc.

So I decided to embark on a journey to modernize it so one can actually compile it for the platform it was designed for (Ubuntu/Debian). My repo is the result of that. I am a nobody, and given the state of the library, I had no expectation that it were to go beyond my repo. But I was lucky enough to get a Googler attention to my PRs (Thanks @Namburger!) and those were merged. So at least Debian/Ubuntu users can have a modern library as it was intended.

Bazel works very well and seamlessly with Debian/Ubuntu. I'd stress, once again, that those were the officially supported distros. I know the Makefile is old and yet, I don't have the interest and time to deal with it, as Bazel works for me. Given the success, I thought that not everybody is willing to go through the compilation process, and so I provide binaries for people to use. Most appreciate it, as a quick (and frankly the only way) to get their new shiny exdetpu they just bought to run on their just as hiny new Raspberry Pi (without going into details, direct compilation on the PI is a mess, so a cross-compile docker compilation is necessary). Point is, the binaries are designed for these folks.

What about other distro/OS? I don't use or care for Windows, and even if I did, I don't have machines and time to get it done there. I compile for MacOS (since I have a Macbook), also using Bazel. Note that these, along Debian/Ubuntu are the officially supported platforms. What about other distros? I don't use them, and have no way or time or system to do it. And little interest as well.

This is not to dismiss your point, but to describe my journey. You can either adapt to suboptimal solution, or get it done yourself. If someone wants to modernize the makefile, add support for other distros, etc, that would be great. But expecting official help by sending out a bug report to a dead repo is not going to work, other than having people like me providing the little but of help we may offer to get it going within the existing infrastructure. The alternative is to get to work, fix what's broken and share it for other to use.

I hope this helps. Again, I don't mean to dismiss the concern, but to provide the context of what is needed to achieve your stated goals. Of course we should all blame Google for dismal support for a great library, but you know Google is Google.

[feranick]

I am not sure this helps, but a PR exists to modernize the makefile. Maybe there is something there for you.

#66

[mwprado]

I am not sure this helps, but a PR exists to modernize the makefile. Maybe there is something there for you.

#66

I sent a patch file for internal makefile and was tested in fedora 40.