<div dir="ltr">Hi Robert,<div><br></div><div>Thanks so much for the speedy response. That is certainly dangerous looking. I'm sure everyone will want to buy me a beer/coffee after I crash their machines during configuration. I almost wish you had responded "impossible" because now I have the temptation of trying it out!</div><div><br></div><div>Thanks,</div><div>Zaak</div><div><br></div><div><div dir="ltr"><div dir="ltr">Izaak "Zaak" Beekman<br><br>------------------------------------------------------------------------------- <br>HPC Scientist<br><a href="http://www.paratools.com/" target="_blank">ParaTools Inc.</a><br>5520 Research Park Drive<br>Suite 100<br>Baltimore, MD 21228<br>phone: <a href="tel:(443)%20543-5059" value="+14435435059" target="_blank">(443) 543-5059</a><br>mobile: <a href="tel:(917)%20797-3239" value="+19177973239" target="_blank">(917) 797-3239</a><br>-------------------------------------------------------------------------------</div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 4, 2018 at 12:07 PM Robert Maynard <<a href="mailto:robert.maynard@kitware.com">robert.maynard@kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">See <a href="https://cmake.org/pipermail/cmake/2011-March/043320.html" rel="noreferrer" target="_blank">https://cmake.org/pipermail/cmake/2011-March/043320.html</a> for a<br>
discussion on overloading functions and the dangers that can occur.<br>
<br>
<br>
On Wed, Apr 4, 2018 at 11:38 AM, Zaak Beekman <<a href="mailto:zbeekman@gmail.com" target="_blank">zbeekman@gmail.com</a>> wrote:<br>
> I have been moving towards modern CMake where<br>
> includes/compiler-flags/libraries/etc. are using target properties and<br>
> transitive usage requirements which has greatly simplified setting up Modern<br>
> Fortran build systems. In addition, if you're going to vendor all/most of<br>
> your package's dependencies and just configure them along with your package<br>
> with a simple `add_subdirectory()` call this allows you to setup projects<br>
> that may be consumed in this way by parent projects or used on their own.<br>
> This is super convenient, and IMO, easier to understand and deal with than<br>
> super builds. The propagation of transitive properties makes this relatively<br>
> easy and seamless.<br>
><br>
> However, until I/we have time to improve the OpenCoarrays CMake<br>
> `find_package` support some of the projects my colleagues are writing/using<br>
> set the OpenCoarrays compiler wrapper script, `caf`, as $FC before invoking<br>
> CMake. This is fine until it some parent project is using<br>
> GFortran+OpenCoarrays and a child project may not need Coarrays at all.<br>
> Everything proceeds find until the tests are run because, at least on some<br>
> systems, executables will hang when compiled against MPI/Opencoarrays<br>
> without the MPI job launcher scripts being used to launch the test<br>
> executable.<br>
><br>
> I realize I can write my own function/macro and just call it from all the<br>
> projects to decide how the tests should be launched---with `cafrun` if<br>
> compiled by the `caf` wrapper script or by directly calling the executable<br>
> if compiled with GFortran. And, yes, I know that the real solution to this<br>
> problem is to improve the CMake support of OpenCoarrays... but time is<br>
> scarce at the moment.<br>
><br>
> So, my question is: Can I overload/shadow/redefine the intrinsic<br>
> `add_test()` cmake command?<br>
><br>
> This way if the child project calls `add_test()` the parent project can<br>
> redefine it if needed. Otherwise, the child project will run as intended<br>
> when configured and built on its own (i.e. just with GFortran, w/o coarray<br>
> support & OpenCoarrays).<br>
><br>
> Thanks,<br>
> Zaak<br>
><br>
> Izaak "Zaak" Beekman<br>
><br>
> -------------------------------------------------------------------------------<br>
> HPC Scientist<br>
> ParaTools Inc.<br>
> 5520 Research Park Drive<br>
> Suite 100<br>
> Baltimore, MD 21228<br>
> phone: <a href="tel:(443)%20543-5059" value="+14435435059" target="_blank">(443) 543-5059</a><br>
> mobile: <a href="tel:(917)%20797-3239" value="+19177973239" target="_blank">(917) 797-3239</a><br>
> -------------------------------------------------------------------------------<br>
><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:<br>
> <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<br>
> 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<br>
> <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="https://cmake.org/mailman/listinfo/cmake" rel="noreferrer" target="_blank">https://cmake.org/mailman/listinfo/cmake</a><br>
><br>
</blockquote></div>