"Config-less" configuration

[cmauney]

Removed PORTABILITY_STRATEGY_* target properties & cache vars.

PR Summary

The compiler defines PORTABILITY_STRATEGY_* only find expression after the compiler preprocessor has parsed the source. Therefore, these defines are best left to the host code. This has some useful advantages:

• easier maintenance of ports-of-call - the build system (modulo any future testing infrastructure) just needs to install the headers and provide the include paths downstream.
• flexibility; for whatever PORTABILITY_STRATEGY is used by the host code, only one install of ports-of-call is needed.

I may be out over my skis on this, so if it seems as tho I've misread something let me know.

Changes:

• removed options/cache vars from CMakeLists.txt.
• moved c++ standard from cmake cache to target property, and changed to c++14
• moved ports-of-callConfig.cmake.in to cmake/ports-of-callConfig.cmake; this is more inline with standard practice.
• removed export(PACKAGE ...); this is rarely used (for our main codes, or in the wild) and could cause some issues with cmake's hairbrained packaging scheme
• removed logic around CMAKE_BUILD_TYPE - we don't build anything.
• small formatting changes with no effects on functionality

PR Checklist

• [x] Any changes to code are appropriately documented.
• [x] Code is formatted.
• [x] Install test passes.
• [x] Docs build.

[mauneyc-LANL]

@jonahm-LANL @dholladay00 @jhp-lanl

Created this on my personal github account by mistake, just verifying it was me

[Yurlungur]

I think the biggest advantage here is actually from an install perspective---ports-of-call installations no longer carry around PORTABILITY_STRATEGY in their cmake so you only need one for several different builds.

[chadmeyer]

This seems like an OK philosophy to follow. Honestly, short of having any ideas of how this will work out in Fortran eventually (if at all), I don't see any reason to suggest otherwise. Can we make sure that we update a description somewhere (README?) to clarify how this would be used in downstream libraries or codes?

[Yurlungur]

That sounds good. Thanks for the double check, @chadmeyer . @mauneyc-LANL can you update the docs/README? After that let's merge this in.

[mauneyc-LANL]

This seems like an OK philosophy to follow. Honestly, short of having any ideas of how this will work out in Fortran eventually (if at all), I don't see any reason to suggest otherwise. Can we make sure that we update a description somewhere (README?) to clarify how this would be used in downstream libraries or codes?

I've updated README.md with a short section, let me know if it looks okay

[Yurlungur]

That looks good. Let's also add the necessary tweaks here: https://github.com/lanl/ports-of-call/blob/main/doc/sphinx/src/building.rst

[dholladay00]

Is this waiting on anything @Yurlungur @mauneyc-LANL ?

[mauneyc-LANL]

Is this waiting on anything @Yurlungur @mauneyc-LANL ?

Give me a minute to update docs

[mauneyc-LANL]

Is this waiting on anything @Yurlungur @mauneyc-LANL ?

Give me a minute to update docs

I've updated to docs, please let me know if this is acceptable @dholladay00 @jonahm-LANL