Hi Robert, 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!
Thanks, Zaak Izaak "Zaak" Beekman ------------------------------------------------------------------------------- HPC Scientist ParaTools Inc. <http://www.paratools.com/> 5520 Research Park Drive Suite 100 Baltimore, MD 21228 phone: (443) 543-5059 mobile: (917) 797-3239 ------------------------------------------------------------------------------- On Wed, Apr 4, 2018 at 12:07 PM Robert Maynard <[email protected]> wrote: > 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
