<div dir="ltr">Craig,<div><br></div><div>I'm sorry for my previous answer which I wrote in haste. Now I've read your SO post and realized the question is a bit more complex then "is execute_process safe instead of ExternalProject".</div><div><br></div><div>Anyway I still think your approach is basically correct. I have the following comments:</div><div><br></div><div>- I wouldn't re-use the current build dir and would build mycomp always in it's own build dir. Also, I'd always use the plain default cmake generator (which is a must when crosscompiling anyway). No need to forward any settings to it from the superbuild. Also, I'd always build the Release config for mycomp.</div><div><br></div><div>- You could "install(TARGETS mycomp DESTINATION bin)" in your EARLY_BUILD then later use "find_program(mycomp_EXECUTABLE mycomp ...) later to save guessing the executable's name.</div><div><br></div><div>Tamas</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 1, 2016 at 9:25 PM, Tamás Kenéz <span dir="ltr"><<a href="mailto:tamas.kenez@gmail.com" target="_blank">tamas.kenez@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">Craig,<div><br></div><div>My cmake-based build system in my company's CI framework works exactly that way: there's a generic cmake script[1] (invoked with cmake -P) that reads in a file which contains repo-urls and build parameters for 50+ projects and builds them for 3 platforms (linux, win, mac) 5 compilers (cross-compilers, too) invoking child cmake builds with execute_process. This is done after each push and one daily clean build.</div><div><br></div><div>I've never had any problems with that approach.</div><div><br></div><div>On the other hand, the system was originally designed with ExternalProject and I had many problems.</div><div><br></div><div>[1]: <a href="https://github.com/tamaskenez/centralbuilder" target="_blank">https://github.com/tamaskenez/centralbuilder</a></div><div><br></div><div>Tamas</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Apr 1, 2016 at 1:53 AM, Craig Scott <span dir="ltr"><<a href="mailto:craig.scott@crascit.com" target="_blank">craig.scott@crascit.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>All,</div><div><br></div><div>I originally planned to ask this question directly on this mailing list, but it got a bit more involved, so I posted it to stackoverflow instead. I'm interested if anyone can shed some more authoritative light on the proposed method for the following question:</div><div><br></div><div><a href="http://stackoverflow.com/q/36084785/1938798" target="_blank">http://stackoverflow.com/q/36084785/1938798</a><br></div><div><br></div><div><b>Short version</b>: invoke a nested cmake-and-build immediately within the main CMake run to build a specific target via execute_process(). This makes that tool available for use still within the same (main) CMake run. An ExternalProject-based technique would normally be a better solution, but in this particular case, that wasn't possible.</div><div><br></div><div>I'd be interested if anyone can confirm whether the suggested approach is guaranteed to be safe for all generators and platforms, or whether there are other factors I have not considered in the proposed technique.</div><div><br></div><div>Cheers<span><font color="#888888"><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>
</font></span></div></div>
<br></div></div>--<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>
</blockquote></div><br></div></div>