See https://cmake.org/pipermail/cmake/2011-March/043320.html for a discussion on overloading functions and the dangers that can occur.
On Wed, Apr 4, 2018 at 11:38 AM, Zaak Beekman <[email protected]> wrote: > I have been moving towards modern CMake where > includes/compiler-flags/libraries/etc. are using target properties and > transitive usage requirements which has greatly simplified setting up Modern > Fortran build systems. In addition, if you're going to vendor all/most of > your package's dependencies and just configure them along with your package > with a simple `add_subdirectory()` call this allows you to setup projects > that may be consumed in this way by parent projects or used on their own. > This is super convenient, and IMO, easier to understand and deal with than > super builds. The propagation of transitive properties makes this relatively > easy and seamless. > > However, until I/we have time to improve the OpenCoarrays CMake > `find_package` support some of the projects my colleagues are writing/using > set the OpenCoarrays compiler wrapper script, `caf`, as $FC before invoking > CMake. This is fine until it some parent project is using > GFortran+OpenCoarrays and a child project may not need Coarrays at all. > Everything proceeds find until the tests are run because, at least on some > systems, executables will hang when compiled against MPI/Opencoarrays > without the MPI job launcher scripts being used to launch the test > executable. > > I realize I can write my own function/macro and just call it from all the > projects to decide how the tests should be launched---with `cafrun` if > compiled by the `caf` wrapper script or by directly calling the executable > if compiled with GFortran. And, yes, I know that the real solution to this > problem is to improve the CMake support of OpenCoarrays... but time is > scarce at the moment. > > So, my question is: Can I overload/shadow/redefine the intrinsic > `add_test()` cmake command? > > This way if the child project calls `add_test()` the parent project can > redefine it if needed. Otherwise, the child project will run as intended > when configured and built on its own (i.e. just with GFortran, w/o coarray > support & OpenCoarrays). > > Thanks, > Zaak > > Izaak "Zaak" Beekman > > ------------------------------------------------------------------------------- > HPC Scientist > ParaTools Inc. > 5520 Research Park Drive > Suite 100 > Baltimore, MD 21228 > phone: (443) 543-5059 > mobile: (917) 797-3239 > ------------------------------------------------------------------------------- > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
