Can't depend on non-cc_library libraries in libs

[zrlk]

It's unclear why Bazel forbids depending on rules that are not instances of the builtin cc_library for libs inputs to other rules. This would allow, among other things, a C++ version of genproto. (The Java version works because the code explicitly allows it: see bazel/src/main/java/com/google/devtools/build/lib/bazel/rules/java/BazelJavaRuleClasses.java:118).

[ulfbot]

I think you mean 'deps', not 'libs'. Allowing genproto in deps of
java_library or cc_library is wrong on so many levels.

Let me try to describe the model of how I think this should work:
java_library.srcs -> .java source files, maybe Java translation files
java_library.deps -> rules with a 'Java nature', such as java_library,
java_import, and other rules that are fully interoperable, such as
groovy_library or scala_library

cc_library.srcs -> this is a bit tricky; gcc takes a lot of different
files, and decides what to do with them by extension; we certainly want to
allow .c and .cc
cc_library.deps -> rules with a 'C/C++ nature', such as cc_library,
cc_import (doesn't exist yet)

If you want to import other files, such as precompiled .jar or .so files,
then you shouldn't use _library, but instead use a special rule
for that import. java_import for importing .jar files, and cc_import for
importing .a or .so files plus corresponding headers.

When you want to use a proto rule, the main question is, does it have a
C/C++ nature or doesn't it? If you generate .c or .cc source files, then it
should go into srcs (or maybe hdrs), not deps. If you generate .c or .cc
source files and then compile them to .a / .so in a way that is compatible
with cc_library, then it should go into deps. However, right now we have
(as you discovered) a hard-coded list of rules that are allowed in deps.
Instead, we want to decide what's allowed in deps by whether the C/C++
nature is implemented by the rule. In terms of code, that means whether the
rule has a C++ provider, such as this one:
https://github.com/google/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/cpp/CcLinkParamsProvider.java

(I would also like to merge the various Cc*Providers into a single
CcProvider, as all rules compatible with cc_library need to have all of
them.)

Internally, we have a proto_library rule which has both the Java and C/C++
nature, so it generally gets placed into deps. We have an alternative plan
for that in bazel, where the proto_library rule itself does not have any
language-specific nature, but instead we use aspects to add it after the
fact. This could potentially look something like this:
cc_library.deps = ["//my/proto/rule:proto#//proto_aspects:cpp+grpc"]

This is also not implemented yet, at least not entirely. We have parts of
aspects support in the code base. Also, the Cc*Providers aren't fully
integrated with Skylark, so it's currently difficult to write Skylark rules
that interop with the native rules.

This ended up a bit long. Short answer is, for now, generate .c / .cc files
and put them into cc_library.srcs.

On Mon, Apr 13, 2015 at 6:53 PM, zrlk notifications@github.com wrote:

It's unclear why Bazel forbids depending on rules that are not instances
of the builtin cc_library for libs inputs to other rules. This would
allow, among other things, a C++ version of genproto. (The Java version
works because the code explicitly allows it: see
bazel/src/main/java/com/google/devtools/build/lib/bazel/rules/java/BazelJavaRuleClasses.java:118).

—
Reply to this email directly or view it on GitHub
#114.

[hanwen]

ulf, can we close this, or is there something left to do?

[ulfjack]

I'm closing this as there's no short term action item here. Longer term, we may want to audit the rules and lock down the semantics (but then again, we may never get to that because so much else is important). :-(

[smr277]

I'm just wondering - what's the status on this? I've found proto_library (http://bazel.io/docs/be/protocol-buffer.html) but it has little to no documentation, and I can't seem to get it to work with cc_library. What's the current protocol (no pun intended) for building and using proto messages with a cc_library?

[ulfjack]

We don't have an out-of-the-box solution for proto messages with cc_library, yet. proto_library is undocumented because it's not ready yet, and it won't work the same way as proto_library works inside Google (in case you have knowledge of that). Sorry, this is all very vague and handwavy - we should really publish our plans around proto_library support.

Maybe file a feature request for C++ protobuf support?