Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2017-09-02T03:07:56Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1270Framework: links to subprojects on dashboard are incorrect2017-09-02T03:07:56ZJames WillenbringFramework: links to subprojects on dashboard are incorrect*Created by: jhux2*
@trilinos/framework
At the top of the MueLu testing [page](http://testing.sandia.gov/cdash/index.php?project=Trilinos&subproject=MueLu) are links to Subproject Dependencies. Those links have the form http://test...*Created by: jhux2*
@trilinos/framework
At the top of the MueLu testing [page](http://testing.sandia.gov/cdash/index.php?project=Trilinos&subproject=MueLu) are links to Subproject Dependencies. Those links have the form http://testing.sandia.gov/cdash/index.php?subproject=<some_package>&, but clicking on any of those links redirects to http://testing.sandia.gov/cdash/viewProjects.php.
I believe the correct form of those links should be http://testing.sandia.gov/cdash/index.php?project=Trilinos&subproject=<some_package>.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1272Trilinos config problem in FiniteValue.cmake and GCC 5.4.02017-05-01T02:17:41ZJames WillenbringTrilinos config problem in FiniteValue.cmake and GCC 5.4.0*Created by: raovgarimella*
Trilinos 12.6.1 and 12.10.1 configuration fails with gcc 5.4.0 and cmake 3.5.1 because of an issue with trilinos/cmake/tribits/core/config_tests/FiniteValue.cmake. The complaint is that "```isnan was not dec...*Created by: raovgarimella*
Trilinos 12.6.1 and 12.10.1 configuration fails with gcc 5.4.0 and cmake 3.5.1 because of an issue with trilinos/cmake/tribits/core/config_tests/FiniteValue.cmake. The complaint is that "```isnan was not declared in this scope```".
Upon investigating further, it seems that FiniteValue.cmake tries to test for existence of '```isnan```' within the global namespace and the ```std::``` namespace but in both cases uses the ```<cmath>``` header.
According to the following post on StackOverflow, it seems however that one should include ```<math.h>``` when calling '```isnan```' and ```<cmath>``` when calling '```std::isnan```'
http://stackoverflow.com/questions/18128899/is-isnan-in-the-std-namespace-more-in-general-when-is-std-necessary-optio
Making this change allows the configuration to proceed. I checked and this problem persists in the HEAD version of the master as well.
Here is a trivial patch file for fixing the problem in 12.10.1 release
```
--- cmake/tribits/core/config_tests/FiniteValue.cmake 2016-11-22 15:43:07.000000000 -0700
+++ cmake/tribits/core/config_tests/FiniteValue.cmake.new 2017-04-26 22:27:08.016402800 -0600
@@ -58,7 +58,7 @@ INCLUDE(CheckCXXSourceCompiles)
SET(SOURCE_GLOBAL_ISNAN
"
-#include <cmath>
+#include <math.h>
int main()
{
double x = 1.0;
@@ -105,7 +105,7 @@ ENDIF()
SET(SOURCE_GLOBAL_ISINF
"
-#include <cmath>
+#include <math.h>
int main()
{
double x = 1.0;
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1293Document information concerning Clean, Nightly, and Specialized tracks2018-02-12T20:58:34ZJames WillenbringDocument information concerning Clean, Nightly, and Specialized tracks*Created by: jwillenbring*
@william76
I need to document the definition of, qualifications for, and process for moving between the 3 new tracks that we are dividing the Nightly track into for automated testing. Definition of done fo...*Created by: jwillenbring*
@william76
I need to document the definition of, qualifications for, and process for moving between the 3 new tracks that we are dividing the Nightly track into for automated testing. Definition of done for this story is:
Trilinos GitHub wiki page exists listing
--Three develop branch testing tracks - Clean, Nightly, and specialized, with a description of each track.
--Process for moving from one track to another.Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1338Disable Fortran by default for Trilinos on Mac OSX machines as well?2017-05-18T19:27:07ZJames WillenbringDisable Fortran by default for Trilinos on Mac OSX machines as well?*Created by: bartlettroscoe*
**CC:** @trilinos/developers, @trilinos/framework
**Description:**
Given that most Mac OSX machines don't have a working Fortran compiler by default, should we change the CMake logic to disable Fortran...*Created by: bartlettroscoe*
**CC:** @trilinos/developers, @trilinos/framework
**Description:**
Given that most Mac OSX machines don't have a working Fortran compiler by default, should we change the CMake logic to disable Fortran by default on Mac OSX machines? That will technically break backward compatibility but given the you don't need Fortran to get a lot out of Trilinos, I am not sure how many users would notice.
I am asking this since I am modifying TriBITS to fix a defect in how it handles the default for `<Project>_ENABLE_Fortran` and I want to move all special platform-specific logic to the project itself. Since I will be updating Trilinos/CMakeLists.txt for this refactoring, I thought I would ask about since I could make this change at the same time.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1355Disable external repos for parameterized builds2017-05-23T17:09:04ZJames WillenbringDisable external repos for parameterized builds*Created by: bmpersc*
Based on a discussion regarding sundance failures on the clean build the Framework team decided it was best to just disable all of the packages that come from external repos for non-specialized builds.
Currently...*Created by: bmpersc*
Based on a discussion regarding sundance failures on the clean build the Framework team decided it was best to just disable all of the packages that come from external repos for non-specialized builds.
Currently there is an option in the configure "Trilinos_EXTRA_REPOSITORIES" that is set to the empty string, but this doesn't seem to be affecting what external repos are pulled in. This needs to be investigated on how to prevent the the external repos from being automatically pulled in.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1362Record pushes to Trilinos 'develop' for later analysis2017-06-03T19:21:49ZJames WillenbringRecord pushes to Trilinos 'develop' for later analysis*Created by: bartlettroscoe*
**Next Action Status:**
Trilinos pushes are being logged to local machine crf450. Next: See 'tasks' below ...
**Description:**
In order to analyze who is pushing commits to the Trilinos GitHub 'dev...*Created by: bartlettroscoe*
**Next Action Status:**
Trilinos pushes are being logged to local machine crf450. Next: See 'tasks' below ...
**Description:**
In order to analyze who is pushing commits to the Trilinos GitHub 'develop' branch and what impact that has on the stability of the 'develop' branch, we need to a way to record who is pushing and when. Unfortunately, GitHub does not give you a way to do that. However, it is pretty easy to set up some simple scripts that continuously pull from the Trilinos GitHub 'develop' branch and then record the top commit when any new commits are discovered. What that data built up over a period of weeks and months, and comparing to the Trilinos post-push CI build (see #482), we can do the analysis that we need to do and determine how to best stabilize the 'develop' branch (which is very important for some customers of Trilinos like ATDM).
**Tasks:**
1) Get initial scripts up and running and logging pushes [Done]
2) Put under version control [Done]
3) Modify the script so that it prepends the top commit instead of putting it at the end (this will be slower but will be more readable) [Done]
4) Find a way to publish this online and link to this from Trilinos GitHub wiki ...
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1388Get templated code in Trilinos to use ETI as much as possible to reduce (re)b...2017-06-02T23:46:23ZJames WillenbringGet templated code in Trilinos to use ETI as much as possible to reduce (re)build times and resources*Created by: bartlettroscoe*
**Blocked By:** (The ETI issues for individual packages as they get created.)
**CC:** @trilinos/framework, @rppawlo, @maherou
**Description:**
This story is a place marker to push the issue of gett...*Created by: bartlettroscoe*
**Blocked By:** (The ETI issues for individual packages as they get created.)
**CC:** @trilinos/framework, @rppawlo, @maherou
**Description:**
This story is a place marker to push the issue of getting templated packages in Trilinos to use explicit template instantiation (ETI) to reduce build times and especially rebuild times for these packages. Long build times is a huge impediment to development, testing, and usage of Trilinos.
For example, it is reported (by @dridzal) that some ROL examples consume huge amounts of compiler time and system memory in order to compile because they directly include headers from Belos, Amesos2, Ifpack2, MueLu, etc. If ETI was being used by these packages, then it is likely that those examples would compile much more quickly and use less memory.
Another example is the xSDK project where Trilinos is constantly getting hit for large build times and resources. (In fact, the xSDK installer for Trilinos was modified to remove the templated packages because of this.)
Now that Trilinos has top-level options for enabling/disabling scale types like `float`, `complex<float>`, and `complex<double>` (see #362, and there are similar options for ordinal types), every Trilinos package that has templated code needs to, as much as possible, provide for ETI based on those requested types. Note that this does *not* require packages to use a consistent system for ETI (hence, #546 is not needed). It just requires that they do ETI and respond to those type enables/disables.
It is expected that new Issues will be created for specific packages to get their code to use ETI more. Those new issues will block this Issue.
Reduce build times for Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1416Question: Nightly testing with large or internal Sandia data files2017-10-20T21:21:20ZJames WillenbringQuestion: Nightly testing with large or internal Sandia data files*Created by: ndellingwood*
What is the best way (if possible) to set up a nightly test that may use large data files or internal data files that cannot be stored within Trilinos?
In particular for Amesos2, we'd like to set up a night...*Created by: ndellingwood*
What is the best way (if possible) to set up a nightly test that may use large data files or internal data files that cannot be stored within Trilinos?
In particular for Amesos2, we'd like to set up a nightly test for the following cases:
1. Using matrix market files provided by a customer that cannot be released in Trilinos for a unit test that would catch issues like those in #1289
2. Potentially using a larger matrix market file for performance testing (e.g. 60MB+).
On this topic, what is the threshold for size of data files allowed to be stored in Trilinos?
@bmpersc @maherou @srajama1 @bartlettroscoe
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1422Get all SERIAL tests in Trilinos to run as 1-process tests in MPI builds2017-08-22T19:15:01ZJames WillenbringGet all SERIAL tests in Trilinos to run as 1-process tests in MPI builds*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Description:**
A big problem we have with SQA and test of Trilinos is that many Trilinos packages have significant numbers of tests that only run in a non-MPI serial buil...*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Description:**
A big problem we have with SQA and test of Trilinos is that many Trilinos packages have significant numbers of tests that only run in a non-MPI serial build (e.g. Pamgan #1415 and SEACAS #1392). That means that running the standard CI build MPI_RELEASE_DEBUG_SHARED_PT does not run any of these tests.
This story is to create a place-marker for package-specific stories to get all of their single-process tests now running only in the non-MPI serial build to also run in the MPI builds. This way, the set of tests run in a serial build will be a strict subset of the tests run in the MPI build. Therefore, passing the MPI build will give higher confidence that the serial build will also pass all of its tests.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1427-openmp option is deprecated in icpc2017-08-23T20:08:19ZJames Willenbring-openmp option is deprecated in icpc*Created by: srajama1*
When enabling OpenMP with intel 17 I get tons of these
icpc: command line remark #10411: option '-openmp' is deprecated and will be removed in a future release. Please use the replacement option '-qopenmp'
C...*Created by: srajama1*
When enabling OpenMP with intel 17 I get tons of these
icpc: command line remark #10411: option '-openmp' is deprecated and will be removed in a future release. Please use the replacement option '-qopenmp'
Can we change the configure logic to handle this ?
@trilinos/framework @bartlettroscoe https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1457Set up new continuous builds2017-08-02T01:27:34ZJames WillenbringSet up new continuous builds*Created by: jwillenbring*
@trilinos/framework
In alignment with the discussion at the Framework Standup this morning, we need to set up 2 new continuous builds on the newer build farm - one to support GCC 4.8.4, the other to suppor...*Created by: jwillenbring*
@trilinos/framework
In alignment with the discussion at the Framework Standup this morning, we need to set up 2 new continuous builds on the newer build farm - one to support GCC 4.8.4, the other to support GCC 4.9.3.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1468Improper python environment on test machine hansel2017-06-30T19:54:49ZJames WillenbringImproper python environment on test machine hansel*Created by: jhux2*
@trilinos/framework There appears to be a problem with the python environment on the test machine ```hansel.sandia.gov```. As a result, two ML tests are failing for the 12.10.1 release. The symptom is
```
'imp...*Created by: jhux2*
@trilinos/framework There appears to be a problem with the python environment on the test machine ```hansel.sandia.gov```. As a result, two ML tests are failing for the 12.10.1 release. The symptom is
```
'import site' failed; use -v for traceback
Traceback (most recent call last):
File "/jenkins/slave/workspace/Trilinos_hansel_release_12.10/MPI_RELEASE_12.10.1_SHARED/Trilinos/commonTools/test/utilities/compareTestOutput", line 9, in <module>
import re
ImportError: No module named re
```
Errors can be found [here](https://testing.sandia.gov/cdash/testDetails.php?test=39699947&build=2975943) and [here](https://testing.sandia.gov/cdash/viewTest.php?onlyfailed&buildid=2975354).https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1480Headers need to use <mpi.h> instead of "mpi.h"2017-07-14T14:49:43ZJames WillenbringHeaders need to use <mpi.h> instead of "mpi.h"*Created by: bangerth*
We got a bug report for deal.II that in essence shows this error message:
```
In file included from /usr/local/include/ml_epetra_utils.h:42:0,
from /usr/local/include/ml_MultiLevelPre...*Created by: bangerth*
We got a bug report for deal.II that in essence shows this error message:
```
In file included from /usr/local/include/ml_epetra_utils.h:42:0,
from /usr/local/include/ml_MultiLevelPreconditioner.h:86,
from ~/Downloads/dealii/source/lac/trilinos_precondition_ml.cc:33:
/usr/local/include/mpi.h:157:16: error: redefinition of ‘struct MPI_Status’
typedef struct MPI_Status {
^~~~~~~~~~
In file included from ~/Downloads/dealii/build/include/deal.II/base/config.h:328:0,
from ~/Downloads/dealii/include/deal.II/lac/trilinos_index_access.h:19,
from ~/Downloads/dealii/source/lac/trilinos_precondition_ml.cc:16:
/opt/intel/compilers_and_libraries/linux/mpi/include64/mpi.h:679:16: note: previous definition of ‘struct MPI_Status’
```
Note how the conflicting declarations come from `/usr/local/include/mpi.h` and `/opt/intel/compilers_and_libraries/linux/mpi/include64/mpi.h`.
The reason is that the user is compiling with the Intel compiler which, via a `-I` flag, provides the `mpi.h` in `/opt/intel/compilers_and_libraries/linux/mpi/include64`. This resolves all instances of `#include <mpi.h>`.
Maybe in a poor choice, the user installed *both* Trilinos and another MPI installation in `/usr/local`, and so when a Trilinos header uses the double-quoted form `#include "mpi.h"`, the compiler *first* looks into `/usr/local/include` and only then into the paths listed via `-I`. Normally that would do no harm since no `mpi.h` is found, but now it is, and the conflict happens.
The problem is because we have this in `ml_epetra_utils.h`:
```
ifdef ML_MPI
#ifndef EPETRA_MPI
#define EPETRA_MPI
#endif
#include "mpi.h" *****************
#endif
```
This should really be `#include <mpi.h>` instead of the double-quoted form. I find other instances of this bug in the following files:
```
> grep '"mpi.h"' *h
Epetra_Time.h:#include "mpi.h"
MLAPI_Workspace.h:#include "mpi.h"
ml_epetra_utils.h:#include "mpi.h"
ml_smoother.h:#include "mpi.h"
```
These are all bugs waiting to happen.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1483Make the parameterized builds capable of changing the configure through a jen...2017-07-10T14:58:26ZJames WillenbringMake the parameterized builds capable of changing the configure through a jenkins parameter*Created by: bmpersc*
@trilinos/framework a question about using a parameter to change the configuration of the parameterized builds was brought up in another issue. We should discuss the pros and cons of that here.
The initial conce...*Created by: bmpersc*
@trilinos/framework a question about using a parameter to change the configuration of the parameterized builds was brought up in another issue. We should discuss the pros and cons of that here.
The initial concern was mentioned in #1393 and was brought up because to resolve that ticket for the clean build we are going to disable the offending tests. However, the easy way to do that for now is to modify the configuration of the parameterized build which would affect more than just the clean builds that we are trying to fix.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1541Framework: Upgrade the buld Linux-GCC-4.7.2-CONTINUOUS_MPI_OPT_DEV_SHARED to ...2018-03-22T17:59:40ZJames WillenbringFramework: Upgrade the buld Linux-GCC-4.7.2-CONTINUOUS_MPI_OPT_DEV_SHARED to GCC 4.8.4 or disable*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Description:**
The build `Linux-GCC-4.7.2-CONTINUOUS_MPI_OPT_DEV_SHARED` with configure output shown at:
* https://testing.sandia.gov/cdash/viewConfigure.php?buildid=3...*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Description:**
The build `Linux-GCC-4.7.2-CONTINUOUS_MPI_OPT_DEV_SHARED` with configure output shown at:
* https://testing.sandia.gov/cdash/viewConfigure.php?buildid=3022476
is still using GCC 4.7.2 shown by:
```
-- CMAKE_C_COMPILER_ID='GNU'
-- CMAKE_C_COMPILER_VERSION='4.7.2'
-- CMAKE_CXX_COMPILER_ID='GNU'
-- CMAKE_CXX_COMPILER_VERSION='4.7.2'
```
Trilinos is no longer supports C++11 builds of Trilinos with GCC versions less than 4.8.4 (see #1453). Therefore, this build needs to be upgraded to GCC 4.8.4. Until this build can be updated, it should be disabled. See history in https://github.com/trilinos/Trilinos/issues/1304#issuecomment-318357060.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1543Get Trilinos to build CUDA Clang-only2017-09-10T04:58:08ZJames WillenbringGet Trilinos to build CUDA Clang-only*Created by: mhoemmen*
Need Clang 4.0 and the CUDA 9 driver.
Request from @crtrott .*Created by: mhoemmen*
Need Clang 4.0 and the CUDA 9 driver.
Request from @crtrott .https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1551Look for SuiteSparse shared libraries too?2017-07-30T02:37:55ZJames WillenbringLook for SuiteSparse shared libraries too?*Created by: ilovezfs*
https://github.com/trilinos/Trilinos/blob/f0350316239aaf41e8e6b82378612aaedf9cc72c/cmake/TPLs/FindTPLCholmod.cmake#L59
Currently Trilinos only looks for the static libraries from SuiteSparse, but the `make inst...*Created by: ilovezfs*
https://github.com/trilinos/Trilinos/blob/f0350316239aaf41e8e6b82378612aaedf9cc72c/cmake/TPLs/FindTPLCholmod.cmake#L59
Currently Trilinos only looks for the static libraries from SuiteSparse, but the `make install` target in SuiteSparse does not install the static libraries, only the shared libraries.
In Homebrew, we're hacking around this for Trilinos by adding this to the SuiteSparse formula:
```
lib.install Dir["**/*.a"]
```
But it would be good if Trilinos were able to build with a stock SuiteSparse installation.
(I have also contracted SuiteSparse upstream to request that `make install` install the static libraries too.)https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1590Make sure Scalar=float gets tested nightly2017-08-08T22:40:43ZJames WillenbringMake sure Scalar=float gets tested nightly*Created by: mhoemmen*
@trilinos/framework
@vbrunini
It turns out that a Sierra product depends on Scalar=float. This means that Trilinos should add nightly tests with `Trilinos_ENABLE_FLOAT:BOOL=ON`.*Created by: mhoemmen*
@trilinos/framework
@vbrunini
It turns out that a Sierra product depends on Scalar=float. This means that Trilinos should add nightly tests with `Trilinos_ENABLE_FLOAT:BOOL=ON`.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1630Recent Kokkos changes require -std=c++11 flag with CUDA 8.0 & GCC 5.32017-09-14T20:34:55ZJames WillenbringRecent Kokkos changes require -std=c++11 flag with CUDA 8.0 & GCC 5.3*Created by: mhoemmen*
@trilinos/framework
It looks like C++11 is not being enabled by default in a CUDA 8.0 + GCC 5.3 build with TpetraCore enabled. When I omit `-std=c++11` from `CMAKE_CXX_FLAGS` in a CUDA 8.0 + GCC 5.3 build wit...*Created by: mhoemmen*
@trilinos/framework
It looks like C++11 is not being enabled by default in a CUDA 8.0 + GCC 5.3 build with TpetraCore enabled. When I omit `-std=c++11` from `CMAKE_CXX_FLAGS` in a CUDA 8.0 + GCC 5.3 build with TpetraCore enabled, I get the following configure-time error:
```
-- MPI_EXEC='/projects/sems/install/rhel6-x86_64/kokkos/compiler/gcc/5.3.0/openmpi/2.0.1/cuda/8.0.44/bin/mpiexec'
-- The C compiler identification is GNU 5.3.0
-- Check for working C compiler: /projects/sems/install/rhel6-x86_64/kokkos/compiler/gcc/5.3.0/openmpi/2.0.1/cuda/8.0.44/bin/mpicc
-- Check for working C compiler: /projects/sems/install/rhel6-x86_64/kokkos/compiler/gcc/5.3.0/openmpi/2.0.1/cuda/8.0.44/bin/mpicc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- CMAKE_C_COMPILER_ID='GNU'
-- CMAKE_C_COMPILER_VERSION='5.3.0'
-- The CXX compiler identification is unknown
-- Check for working CXX compiler: /projects/sems/install/rhel6-x86_64/kokkos/compiler/gcc/5.3.0/openmpi/2.0.1/cuda/8.0.44/bin/mpicxx
-- Check for working CXX compiler: /projects/sems/install/rhel6-x86_64/kokkos/compiler/gcc/5.3.0/openmpi/2.0.1/cuda/8.0.44/bin/mpicxx -- broken
CMake Error at /projects/sems/install/rhel6-x86_64/sems/utility/cmake/3.3.2/share/cmake-3.3/Modules/CMakeTestCXXCompiler.cmake:54 (message):
The C++ compiler
"/projects/sems/install/rhel6-x86_64/kokkos/compiler/gcc/5.3.0/openmpi/2.0.1/cuda/8.0.44/bin/mpicxx"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: .../Trilinos/CHECKIN-CUDA-8.0/MPI_DEBUG_REAL/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/gmake" "cmTC_64169/fast"
/usr/bin/gmake -f CMakeFiles/cmTC_64169.dir/build.make
CMakeFiles/cmTC_64169.dir/build
gmake[1]: Entering directory
`.../Trilinos/CHECKIN-CUDA-8.0/MPI_DEBUG_REAL/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_64169.dir/testCXXCompiler.cxx.o
/projects/sems/install/rhel6-x86_64/kokkos/compiler/gcc/5.3.0/openmpi/2.0.1/cuda/8.0.44/bin/mpicxx
-Wall -expt-extended-lambda -o
CMakeFiles/cmTC_64169.dir/testCXXCompiler.cxx.o -c
.../Trilinos/CHECKIN-CUDA-8.0/MPI_DEBUG_REAL/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:140:1:
warning: identifier ‘static_assert’ is a keyword in C++11
[-Wc++0x-compat]
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:156:1:
warning: identifier ‘decltype’ is a keyword in C++11 [-Wc++0x-compat]
*
^
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:133:29:
error: template argument 1 is invalid
#if defined(__cplusplus) && !defined(__CUDACC_RTC__)
^
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:138:32:
warning: variadic templates only available with -std=c++11 or -std=gnu++11
* *
^
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:140:15:
error: expected identifier before ‘sizeof’
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:140:15:
error: expected ‘,’ or ‘...’ before ‘sizeof’
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:140:104:
error: ISO C++ forbids declaration of ‘static_assert’ with no type
[-fpermissive]
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:145:19:
warning: variadic templates only available with -std=c++11 or -std=gnu++11
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:146:18:
warning: variadic templates only available with -std=c++11 or -std=gnu++11
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:148:49:
warning: variadic templates only available with -std=c++11 or -std=gnu++11
....
```
When I add `-std=c++11` to `CMAKE_CXX_FLAGS`, I am able to configure Trilinos and build TpetraCore library, tests, and examples.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1655find_package option COMPONENTS ineffective because of hard-coded includes in ...2017-08-29T12:54:26ZJames Willenbringfind_package option COMPONENTS ineffective because of hard-coded includes in TrilinosConfig.cmake*Created by: jwuttke*
CMake's find_package takes an option COMPONENTS. Usage with Trilinos seems to be documented nowhere, but TrilinosConfig.cmake clearly is intended to support commands like
find_package(Trilinos REQUIRED COMPO...*Created by: jwuttke*
CMake's find_package takes an option COMPONENTS. Usage with Trilinos seems to be documented nowhere, but TrilinosConfig.cmake clearly is intended to support commands like
find_package(Trilinos REQUIRED COMPONENTS Epetra Belos Ifpack)
However, at the bottom of TrilinosConfig.cmake there is a long list that includes all Trilinos subproject CMake files. This overwrites the component selection, and makes it ineffective: the client application will depend on _all_ of Trilinos, not just on the selected components.