Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Appveyor is passing and I don't think the travis failures are due to this PR. Would someone like to take a look and kick off jenkins?

I think we should fix the build issue of js_embed rather than disabling protoc. More configuration options mean more maintenance overhead. Maybe we just need to tell cmake the js_embed binary is built for host someway?

@xfxyjwf I also agree that reducing the number of options is in general good.

In this case, I am a bit torn mainly because in cross-compilation stages, it would be tricky to require a protoc build because the toolchain would also need a host compiler. For example, when one uses gradle to build Android apps which further uses cmake, it makes life harder if one has to build js_embed for host (for example, it requires one to install the whole XCode).

Mixing cross-compilation and host compilation is also not very well supported by CMake IIRC.

Another option is to pass a protobuf_JS_EMBED_BINARY_PATH pointing to a prebuilt one, but that involves adding an option anyway, so this one is actually more preferred - build what you use and not any more.

For possible solutions, see this thread:

https://cmake.org/pipermail/cmake/2013-January/053253.html

I'm surprised cmake is lacking such basic support for cross-compiling. Without proper support from cmake this PR seems a reasonable workaround.