<div dir="ltr"><div>Another "outside the box" solution that I have had success with is as follows  (Note this solution will only work with Linux):<br><br>You can use the Linux binfmt_misc driver to execute non-native executables through an interpreter.  If you google for qemu binfmt wrapper, you'll find various suitable approaches, but basically, you register a wrapper executable that calls binaries via qemu if the shell detects that it is of a specific type (namely ARM elf).<br><br></div><div>After that, you can run the detected protoc "natively".  Note this also has the side benefit of protoc will always match the version of the protobuf headers.  I had earlier hacked my build system into finding my ARM installaed protobuf headers, but using the native protoc, but it complained because they weren't exactly the same version, which is unsupported under protobuf IIRC.<br><br></div><div>Hope that helps,<br></div><div>Dave<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 24, 2016 at 5:02 PM, Walter Gray <span dir="ltr"><<a href="mailto:chrysalisx@gmail.com" target="_blank">chrysalisx@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">@Hendrik - Yes, unfortunately it didn't help me too much.<div>Superbuilds are not really an appropriate solution here - The project I'm working on is too heavily down an alternative path, and I'm trying to set up the exported .cmake files in the protobuf 3.0 beta to properly support any sort of option. </div><div><br></div><div>I suppose the question I should have asked is 'When setting up exported package config files, what is the best way to handle the case where some users will want to mix and match components based on platform?'. </div><div> <br></div><div>The concept of a protobuf_PROTOC override variable would certainly do the job, but seems like a bit of a hack. I'd like to establish what the canonical 'best practice' for solving this problem should be in a way that supports using pre-built libraries.</div><div><br></div><div>I'm thinking if I split the protobuf project's exports into 2 components, one for the libraries and one for protoc, I can have clients call find_package twice with different search paths and component lists, and add some checks to reject a match if, for example, someone targeting arm tries to link libraries compiled for mac.</div><div><div class="h5"><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">On Mon, May 23, 2016 at 5:17 AM David E DeMarle <</span><a href="mailto:dave.demarle@kitware.com" style="line-height:1.5" target="_blank">dave.demarle@kitware.com</a><span style="line-height:1.5">> wrote:</span><div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Just to clarify, although ParaView's superbuild assists you to set up and compile in either "compile TOOLS" or "CROSS compile" mode (or the default "HOST" mode) the protobuf inclusion I was speaking of in is found within paraview's source code and is not an external project.<div>See ${PVSOURCE}/ThirdParty/protobuf<br></div><div><br></div><div>hope that helps</div></div><div dir="ltr"><div><br>On Saturday, May 21, 2016, Craig Scott <<a href="mailto:craig.scott@crascit.com" target="_blank">craig.scott@crascit.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">There's also the technique described in this stack overflow question/answer:<div><br></div><div><a href="http://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run" target="_blank">http://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run</a><div><br></div></div><div>I'd probably recommend the superbuild approach used by Paraview though if your build can be structured that way. With the superbuild approach, it's a bit easier to tell what's going on. The method in the above link would only be better if you really needed to keep everything in the one single build.</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 21, 2016 at 11:10 PM, David E DeMarle <span dir="ltr"><<a>dave.demarle@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Take a look at paraview's internal copy of protobuf. We compile protoc in the host tools pass and then use it when we build libprotobuf in the cross compile pass. </p>
<div class="gmail_quote">On May 20, 2016 10:14 PM, "Walter Gray" <<a>chrysalisx@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">A small addendum - The way I am currently solving this problem is by replacing the version of protoc in the library folder for android with one that works on the host machine, but this is really not the best since it means that the library distribution is tied to the host AND the target.<div><br></div><div>Thinking in terms of concepts, I think I would want a find_package that understood the difference between finding a package for executing and finding a package for linking, but that'd be a pretty fundamental change.</div><br><div class="gmail_quote"><div dir="ltr">On Fri, May 20, 2016 at 7:02 PM Walter Gray <<a>chrysalisx@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I've got a project with a number of target platforms, including some that I have to cross-compile to such as android, that uses protobuf. If you're unfamiliar, the crux of the issue is that there is both a library, libprotobuf, and an 'compiler', protoc, that takes .proto files and generates a .h/.cc pair that are then included in the project.<div><br></div><div>When cross compiling, want to use the libprotobuf that was compiled on andriod, but the protoc that was compiled for my host environment. How could this be achieved?</div><div><br></div><div>Currently, my build machine has several different directories where I store the external libraries that have been compiled for the various platforms/compilers that we support (Libraries-arm32, Libraries-x64, Libraries-x64-vc14, ect). </div><div><br></div><div>Solutions that require modifying protobuf's -config.cmake file are welcome, I've already submitted several PR's improving it. I'd like to establish what the best practice for this kind of situation is as I have the same issue with Flatbuffers.</div><div><br></div><div>On a slightly unrelated note, is there some way to write something like the AUTOUIC system without modifying cmake itself? It would be lovely if all I had to do was include the .proto file in the source file list.</div><div><br></div><div>Thanks!</div></div><div dir="ltr"><div>Walter</div></div></blockquote></div></div>
<br>--<br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/cmake</a><br></blockquote></div>
<br>--<br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/cmake</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr">Craig Scott<br><div>Melbourne, Australia</div><div><a href="http://crascit.com" target="_blank">http://crascit.com</a><br></div></div></div></div></div>
</div>
</blockquote>
</div></div></blockquote></div></div></div></div></div></div></div>
<br>--<br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/cmake</a><br></blockquote></div><br></div>