More problems with "external" targets

[undernorthernsky]

See also: #5

• broken assumption: it creates a single library object
  • if another .cpp file needs includes (from the lib) the build can fail (as the dependency tree only knows about the library)
• the library is only present in STAGEDIR; you need to write VERBATIM code to install to DESTDIR
  • for now we manually cp to DESTDIR, which is cumbersome; furthermore the -rpath of the external target is still set to STAGEDIR, thus dependencies between external targets might(?) fail to resolve at runtime (LD_LIBRARY_PATH works, does our -rpath to DESTDIR/lib work for the external libs as well?)
• delegating to the external build (configure & make install) does not inherit any -j flag (no parallel build)
• we already have cases where we apply patches to a third-party lib; when the patches change the lib needs to be rebuild

Example use case: protobuf

This scenario will require VERBATIM for the foreseeable future; however it shows how the dependency-tree of the external target can intermingle with the dependencies of our code.

$(STAGEDIR)/lib/libglog.la $(STAGEDIR)/bin/protoc: $(PROTOBUF_TARBALL) $(PROTOBUF_PATCHES)
   # extract, patch, configure, make install
   ...

PROTO_FILES  := foo.proto
PROTO_OUTPUT := foo.pb.h foo.pb.cc

# re-gen if .proto changes; need either system-installed or custom protoc
$(PROTO_OUTPUT): $(PROTO_FILES) $(STAGEDIR)/bin/protoc

# must run protoc before compiling main code
# note: this isn't entirely correct (don't need .pb.cc; not every
#       file is likely to include each .pb.h)
$(MY_OBJ): $(PROTO_OUTPUT)

# need library before attempting to link
$(MY_EXE): $(STAGEDIR)/lib/libglog.la