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 <zbeek...@gmail.com> 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

Reply via email to