[CMake] 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. <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 <robert.maynard at kitware.com>
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 <zbeekman at 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180404/44ac01ce/attachment.html>