A common way for this to work would be to use a static library:
Common/Android.bp:
cc_library_static {
name: "libCommon",
srcs: ["Common.cpp"],
export_include_dirs: ["."],
}
Foo/Android.bp:
cc_library_shared {
name: "libFoo",
static_libs: ["libCommon"],
srcs: ["Foo.cpp"],
}
That works best if the common code is actually common, and doesn't need to try to include Foo.h or Bar.h at build time. It also works in the inverse case, where Foo and Bar can be independently built static libraries included by Common. It has the advantage that there's only one link that provides both the sources and headers, so you can't accidentally forget one, or change one but not the other. It'll also only build Common.cpp once, even if it's used by both libFoo and libBar.
If that's not the case, I'd suggest some refactoring :-) But it is possible to use a header-only library instead, along with a filegroup for the source:
Common/Android.bp:
filegroup {
name: "CommonSrcs",
srcs: ["Common.cpp"],
}
cc_library_headers {
name: "libCommonHdrs",
export_include_dirs: ["."],
}
Foo/Android.bp:
cc_library_shared {
name: "libFoo",
header_libs: ["libCommonHdrs"],
srcs: ["Foo.cpp", ":CommonSrcs"],
}
cc_library_headers is really meant to be used only for header-only libraries -- cases where there are no source files, and everything you need is in the header files. So this is outside the expected use cases, which may cause problems as the build system evolves in the future (though misuses of this are fairly common).
- Dan