Now that gRPC_INSTALL is forced off if using bundled third-party
libraries, it no longer makes sense to set it OFF by default for MSVC.
However, we do want to set it OFF by default if gRPC is being built as a
subproject of another project.
Best practice for Bazel builds gives one rule per target, and producing
multiple targets conflicts with this.
Short term: define macros, and common libraries that can eliminate the
duplication.
Longer term: eliminate the existing plugin registration mechanism, and
replace it with a C++ static initialization in appropriate files. This
will allow grpc to be layered strictly atop grpc_unsecure (and similarly
grpc++ atop grpc++_unsecure and grpc).
`require-relative` breaks Rubygems' ability to use the arch-specific
directory in `extensions`. When building grpc extensions from source,
we're left with a lot of intermediate object files and a duplicate
shared object file as well. This space can be reclaimed by finding these
object files inside the `gems` subdirectory of the installation
location, while leaving the shared object file in the `extensions`
subdirectory. See the comments at
https://github.com/rubygems/rubygems/issues/926 for more on this
behavior, which has been present in Rubygems for years.
By using `require` instead, those of us who build from source can
reclaim space consumed by duplicate and intermediate files, which
amounts to a savings of 46MB (in a build of 1.3.2 on Alpine
Linux). This is helpful when trying to minimize the size of a Docker
image.
I'm unclear on whether or not the reclaiming of this space can be
automated as part of the build process. If so, it may be worth
considering as a separate effort.