On 2022-08-03 14:11 +0200, David Given wrote: > The problem is that bazel loves vendored source. ... It is > possible to force bazel to link against the system libraries but > this sort of thing is considered a bazel anti-pattern, it's hard, > and of course with my upstream hat on I don't want to do it as I > don't want to have to tailor my build system around Debian's > needs. So, what should I do? As bazel takeup increases I expect > this to be a growing problem, so it's not just me. Has anyone > thought of this? Yes. I've had this problem packaging tensorflow. I'm not upstream as well so I have no desire to do things the bazel way, but it is a big pain getting it to do things the distro (proper, reproducible) way. As you are upstream too my advice would be: use a better build system that isn't antithetical to proper distro packaging. There are plenty to choose from these days. I think the long-term solution to this is better bazel support for 'use system libraries'. It does have some but is currently arrange as a lot of work for each package/project. It should be possible to just turn on 'use system libraries' and have it use the right (much simpler as there is no downloading and tarball tagging and path-mangling involved) process, then mark anything which does need to be vendored as using the 'normal' bazel process. This involves some work in bazel from people like us who care about this. The alternative is just maintain a parallel build in a sensible build system (tensorflow now has a parallel cmake build which has largely solved my particular issues). So, yes there are other people affected/interested. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: PGP signature