Moertel: Build failure with Epetra disabled

[tjfulle]

Bug Report

@trilinos/moertel

Description

Moertel requires that if any of

• EpetraExt
• Amesos
• AztecOO
• Ifpack
• ML

is enabled, they all must be enabled.

A problem arises in the following configuration:

-D Trilinos_ENABLE_Tpetra=ON
-D Trilinos_ENABLE_Epetra=OFF
-D Trilinos_ENABLE_ALL_FORWARD_DEP_PACKAGES=ON

because Tpetra is pervasive throughout Trilinos, one of EpetraExt, Amesos, AztecOO, Ifpack, or ML gets enabled due to downstream code being enabled. So is Moertel. The configuration fails because I explicitly disabled Epetra.

@bartlettroscoe Is there a smarter way for Moertel to enforce this requirement? In this case, I'd rather Moertel not be enabled implicitly if its dependencies are not met. Perhaps some setting/logic in Moertel's cmake/Dependencies.cmake that expresses the interconnection between the packages list above that, if any one of the packages is disabled, instructs TriBITs to not enable Moertel?

Related

• Tpetra: Removal of deprecated code meta issue #5602

[bartlettroscoe]

@tjfulle asked:

Perhaps some setting/logic in Moertel's cmake/Dependencies.cmake that expresses the interconnection between the packages list above that, if any one of the packages is disabled, instructs TriBITs to not enable Moertel?

Yes, the general strategies for doing this are described in:

• https://tribits.org/doc/TribitsDevelopersGuide.html#how-to-check-for-and-tweak-tribits-enable-cache-variables

What you want to do is to put in logic that if any of the these packages are explicitly disabled (i.e. ("${${PROJECT_NAME}_ENABLE_<PackageName>}" NOT STREQUAL "" AND NOT ${PROJECT_NAME}_ENABLE_<PackageName>) is TRUE) then set set(${PROJECT_NAME}_ENABLE_Mortel OFF) (and print that you are doing that please).

From looking at:

• https://tribits.org/doc/TribitsDevelopersGuide.html#full-processing-of-tribits-project-files

it might also work to put this logic in Trilinos/packages/mortel/cmake/Dependencies.cmake (that files gets processed before the TriBITS package enable/disable logic is processed). Don't remember a reason not to do that so we could try that as well (and could update documentation to offer this as an option as well).

Does that make sense? If not, I can provide a PR that does this. It is just a few lines of code.

[tjfulle]

Thanks @bartlettroscoe ! I'll go for the first route, since it will be quick and easy and is holding up work on Tpetra's deprecations.

[tjfulle]

Turns out -D Trilinos_ENABLE_ALL_FORWARD_DEP_PACKAGES=ON explicitly sets Tpetra_ENABLE_Moertel=ON (for the original configuration shown), ie, there is no way to detect if the package is set only because it is a forward dependent of Tpetra and not explicitly by the user. There might be a way to do what I want in moertel/cmake/Dependencies.cmake, but it's not a priority.

[bartlettroscoe]

@tjfulle said:

Turns out -D Trilinos_ENABLE_ALL_FORWARD_DEP_PACKAGES=ON explicitly sets Tpetra_ENABLE_Moertel=ON (for the original configuration shown), ie, there is no way to detect if the package is set only because it is a forward dependent of Tpetra and not explicitly by the user.

Can you give a concrete example of what you are seeing? That option should not enable any packages that have been disabled like Moertel (which should be disabled if any of its dependent packages are explicitly disabled as described above). See:

• https://tribits.org/doc/TribitsDevelopersGuide.html#disables-trump-enables-where-there-is-a-conflict

[tjfulle]

Turns out the issue was that Epetra was listed as an optional package when, in fact, it should still be a required package.