Hi Yun,
pkgconfig is supported by autotools and CMake. Ideally, we can have a
`distrib_cc_library` that has only one required argument, `name`. For
instance, when it is `zlib`, Bazel can parse
`/usr/lib/x86_64-linux-gnu/pkgconfig/zlib.pc` to get necessary include
directories, cflags and lib paths. We have to write Bazel rules that
generate pc file, and we would want to have rules that install library
targets along with generated pc file (something like "make install", but
for Bazel).
The new dependency system looks very promising. IMO it deals with the
most annoying problems of Bazel. I hope that it can be implemented soon.
Thanks,
Jesse.
> Hi Jesse,
>
> I'm from the Bazel team and working with Olek on the Bazel Debian
> effort. I'll be very glad to have your help!
>
> > Yeah. However, in practice, it is difficult to set it to `False`. I
> got something like this:
>
> linkstatic = False will force your cc_binary to dynamically link to
> all dependencies whenever possible. If your dependencies are built
> from source, then the binary won't work outside of the Bazel
> working directory.
>
> > However, I noticed that they are kinda tailored/hacked for Debian,
> and they are not really simpler than manual `cc_import` or
> `cc_library` at the moment.
>
> Yes, in fact, the purpose of the distrib_* macros are just to redirect
> targets to the ones in the repo (@debian_cc_deps) for the Debian
> libraries, because we have to switch between building Bazel from
> checked-in source and building Bazel with Debian system libraries.
>
> > I think we can definitely make things easier. Perhaps we can have
> some rules that generate something like `*.pc (pkgconfig)` to install
> to system, so they can be parsed and turned into Bazel targets later.
> Then we can override targets of a project with system-provided ones,
> via naming conventions or mappings or patches.
>
> I like this idea. If you can write a rule to automatically generate
> BUILD files for the system libraries, that already solves half of the
> problem. The other half, as you mentioned, is mapping the targets to
> the Debian ones. The problem is how to make it effortless for users.
>
> Currently, users have to write their own BUILD files for building
> non-Bazel dependencies from source. Check TensorFlow's third party
> directory:
> https://github.com/tensorflow/tensorflow/tree/master/third_party
> <https://github.com/tensorflow/tensorflow/tree/master/third_party>
> We can put something like the distrib_* macros in those BUILD files,
> and users can switch to build with system libraries with just one flag
> (eg. --define=distribution=debian).
>
> But it still requires users to write those BUILD files by hand while
> they can actually be shared. This is where Bazel's new dependency
> management system
> <https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.e6t527rxhw5i>
> could help. We plan to have a Bazel Central Registry that can host
> those BUILD files for non-Bazel projects, so that users don't have to
> write their own. And this is probably a good place to do the target
> mappings. However, the new system is a big design that also aims to
> solve other external dependency problems in Bazel, it will still take
> some time to be available.
>
> Cheers,
> Yun
>
>
>
>
>