Overloading/shadowing/redefining CMake intrinsic commands

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Overloading/shadowing/redefining CMake intrinsic commands

Zaak Beekman
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: <a href="tel:(443)%20543-5059" value="+14435435059" target="_blank">(443) 543-5059
mobile: <a href="tel:(917)%20797-3239" value="+19177973239" target="_blank">(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
Reply | Threaded
Open this post in threaded view
|

Re: Overloading/shadowing/redefining CMake intrinsic commands

Robert Maynard
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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Overloading/shadowing/redefining CMake intrinsic commands

Zaak Beekman
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.
5520 Research Park Drive
Suite 100
Baltimore, MD 21228
phone: <a href="tel:(443)%20543-5059" value="+14435435059" target="_blank">(443) 543-5059
mobile: <a href="tel:(917)%20797-3239" value="+19177973239" target="_blank">(917) 797-3239
-------------------------------------------------------------------------------

On Wed, Apr 4, 2018 at 12:07 PM Robert Maynard <[hidden email]> 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 <[hidden email]> 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: <a href="tel:(443)%20543-5059" value="+14435435059" target="_blank">(443) 543-5059
> mobile: <a href="tel:(917)%20797-3239" value="+19177973239" target="_blank">(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