-
Notifications
You must be signed in to change notification settings - Fork 570
How do I add a feature to Tpetra that should not be enabled by default?
Trilinos developers may at times want to add a feature to Tpetra that should not be enabled or used by default. For example, it may be an experimental algorithm whose benefits have not yet been proven at scale, or a new class whose interface is still in flux. This page gives best practices for doing this.
All new code, and its tests, must build by default. (Don't hide it behind some macro.) That doesn't mean it has to run by default. Keep reading :-)
Always build the test or example by default. Use TRIBITS_ADD_EXECUTABLE
to build the test or example, without running it by default. For example:
TRIBITS_ADD_EXECUTABLE(
my_fancy_test_executable
SOURCES my_fancy_test.cpp
)
Use the upcoming Tpetra_ENABLE_Experimental
CMake option (PR #3872) to protect tests that use "experimental" features. If the option is OFF, the test won't run. (Examples don't usually run as tests, but if they do, the same applies for them.) Use TRIBITS_ADD_TEST
to enable a test that uses an executable. For example:
ASSERT_DEFINED(Tpetra_ENABLE_Experimental) # make sure Tpetra defined this
IF(Tpetra_ENABLE_Experimental)
TRIBITS_ADD_TEST(
my_fancy_test_executable
NAME my_fancy_test_1
ARGS "--which-fancy-test=1"
COMM serial mpi
NUM_MPI_PROCS 1
STANDARD_PASS_OUTPUT
)
ENDIF()
If you want to add an "experimental" code path in an existing Tpetra class or function, do the following:
- Do not protect the code with a macro. THE CODE MUST ALWAYS BUILD.
- Use
Tpetra::Details::Behavior
to disable the code path at run time, by default. - If you can use an existing
Behavior
option, please do so. - Otherwise, create a new
Behavior
run-time option.
If you need to create a new Behavior
run-time option, you may use an existing configure-time option to set the default value of this option. For example, (PR #3872) will define the TPETRA_ENABLE_EXPERIMENTAL
macro. You may use this macro to set the default value of a Behavior run-time option.
Here is an example of how to use Tpetra::Details::Behavior
. In this case, we're using the existing option TPETRA_DEBUG
to enable extra debug checking at run time.
#include "Tpetra_Details_Behavior.hpp"
void whatever_existing_tpetra_function ()
{
using Tpetra::Details::Behavior;
const bool debug = Behavior::debug ();
if (debug) {
// Always builds! No more "this built in release
// mode, but not in debug mode" issues!
do_expensive_debug_mode_checks ();
}
}
Now you can set the TPETRA_DEBUG
environment variable to 0 or 1, to control whether or not to do debug checking. See the documentation of Tpetra::Details::Behavior
for more options.
If your class isn't ready for production, put it in the Tpetra::Experimental
namespace. We can always move it or import it into the Tpetra
namespace later, once it is ready.
Copyright © Trilinos a Series of LF Projects, LLC
For web site terms of use, trademark policy and other project policies please see https://lfprojects.org.
Trilinos Developer Home
Trilinos Package Owners
Policies
New Developers
Trilinos PR/CR
Productivity++
Support Policy
Test Dashboard Policy
Testing Policy
Managing Issues
New Issue Quick Ref
Handling Stale Issues and Pull Requests
Release Notes
Software Quality Plan
Proposing a New Package
Guidance on Copyrights and Licenses
Tools
CMake
Doxygen
git
GitHub Notifications
Mail lists
Clang-format
Version Control
Initial git setup
'feature'/'develop'/'master' (cheatsheet)
Simple centralized workflow
Building
SEMS Dev Env
Mac OS X
ATDM Platforms
Containers
Development Tips
Automated Workflows
Testing
Test Harness
Pull Request Testing
Submitting a Pull Request
Pull Request Workflow
Reproducing PR Errors
Addressing Test Failures
Trilinos Status Table Archive
Pre-push (Checkin) Testing
Remote pull/test/push
PR Creation & Approval Guidelines for Tpetra, Ifpack2, and MueLu Developers