Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2017-05-04T20:32:57Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1188Create jenkins tests for GCC 4.9.3 SERIAL and WError and add to dashboard2017-05-04T20:32:57ZJames WillenbringCreate jenkins tests for GCC 4.9.3 SERIAL and WError and add to dashboard*Created by: william76*
@trilinos/framework
Get tests for GCC 4.9.3 running and put them onto the Experimental CDash board.
So far, these are the tests in the [Experimental](http://testing.sandia.gov/cdash/index.php?project=Trili...*Created by: william76*
@trilinos/framework
Get tests for GCC 4.9.3 running and put them onto the Experimental CDash board.
So far, these are the tests in the [Experimental](http://testing.sandia.gov/cdash/index.php?project=Trilinos##Experimental) dashboard:
- Linux-gcc-4.9.3-SERIAL_Release_gcc_4.9.3__DEV
- @bmpersc pretty much put this one together using his parameterized build.
- Linux-GCC-4.9.3-MPI_Release_Werror_DEV
- I put this together. The CMake scripts are in my fork in the [rhel6-x86_64 directory on my gcc-4.9.3-MPI-Werror branch](https://github.com/william76/Trilinos/tree/gcc-4.9.3-MPI-Werror/cmake/ctest/drivers/rhel6-x86_64).
@jwillenbring , @bmpersc : Have a look at the #WError test that's running under experimental to make sure it's running a reasonable configuration so we can decide if I should put in a pull request to move my CMake files over.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1208Teuchos: Address issus with calling Fortran LAPACK rountines from C++ on Powe...2018-10-14T21:01:05ZJames WillenbringTeuchos: Address issus with calling Fortran LAPACK rountines from C++ on Power8 with GCC/gfortran*Created by: mhoemmen*
**Next Action Status:**
Looks like it was a problem with BLAS and LAPACK after all (see https://github.com/trilinos/Trilinos/issues/2454#issuecomment-386271621).
**Blocks:** #1191
**Duplicates:** #347
*...*Created by: mhoemmen*
**Next Action Status:**
Looks like it was a problem with BLAS and LAPACK after all (see https://github.com/trilinos/Trilinos/issues/2454#issuecomment-386271621).
**Blocks:** #1191
**Duplicates:** #347
**Analogous to:** #1210
**CC:** @trilinos/teuchos @trilinos/framework
**Description:**
**NOTE:** The below original description does not pin-point the actual problem that was causing the failures on 'ride'. The real problem is what appears to be a mixed language calling defect summarized [below](https://github.com/trilinos/Trilinos/issues/1208#issuecomment-298767449).
**Original Description:**
BLAS and LAPACK libraries offer a Fortran 77 interface, but we want to call them from C++ code. This matters both in terms of Fortran function name mangling, and in terms of how to pass arguments into Fortran functions (the "application binary interface" or ABI). Most arguments just go into Fortran from the C or C++ world by pointer. However, some Fortran compilers have a different ABI for passing strings (`CHARACTER(*)`). Some compilers just take `char*`, but others may take `char*, unsigned int` or even `char*, unsigned int*` (or not `unsigned`). Fortran programmers don't see this; only programmers working in other languages (like C or C++), who need to know the Fortran ABI, may see this.
Teuchos' BLAS and LAPACK wrappers have two macros that govern the Fortran string ABI: `CHAR_MACRO(c)` and `Teuchos_fcd`.
`CHAR_MACRO(c)`, defined redundantly in `teuchos/numerics/src/Teuchos_LAPACK.cpp` and `Teuchos_BLAS.cpp`, takes a `const char c` and does the right thing with it to pass it into a Fortran function. Teuchos offers two definitions of `CHAR_MACRO`:
```
#if defined (INTEL_CXML)
#define CHAR_MACRO(char_var) &char_var, one
#else
#define CHAR_MACRO(char_var) &char_var
#endif
namespace {
#if defined (INTEL_CXML)
unsigned int one=1;
#endif
// ...
}
```
Per discussion in #1191, it looks like we need another definition for OpenBLAS on POWER, that passes in the constant `one` by address rather than by value.
`Teuchos_fcd`, defined redundantly in `teuchos/numerics/src/Teuchos_LAPACK_wrappers.hpp` and `Teuchos_BLAS_wrappers.hpp`, has the following definition:
```
#if defined(INTEL_CXML)
# define PREFIX __stdcall
# define Teuchos_fcd const char *, unsigned int
#elif defined(INTEL_MKL)
# define PREFIX
# define Teuchos_fcd const char *
#else /* Not CRAY_T3X or INTEL_CXML or INTEL_MKL */
# define PREFIX
# define Teuchos_fcd const char *
#endif
```
In the comments, `CRAY_T3X` refers to the Cray T3D and T3E, two mid-'90s distributed-memory computer architectures. This should give you an idea of the age of this code. In any case, we would need to add a new definition of Teuchos_fcd:
```
# define Teuchos_fcd const char*, const int*
```
(See comments below for why it's an `int` and not `unsigned int`. It would be better to use `int32_t`, but Teuchos cannot assume C++11 / C99 types.)
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1227Trilinos CI build broken starting on 4/8/2017 with failing NOX and Teko tests2017-04-10T20:10:25ZJames WillenbringTrilinos CI build broken starting on 4/8/2017 with failing NOX and Teko tests*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/teko, @trilinos/nox
Hello @csiefer2 and @tawiesn,
One (or more) of the commits pushed by you to Trilinos 'develop' on 4/8/2017 broke the CI build (with failing t...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/teko, @trilinos/nox
Hello @csiefer2 and @tawiesn,
One (or more) of the commits pushed by you to Trilinos 'develop' on 4/8/2017 broke the CI build (with failing tests NOX_1DfemStratimikosPrec_MPI_4 and Teko_DiagonallyScaledPreconditioner_MPI_1) as shown here:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&filtercount=3&showfilters=1&filtercombine=and&field1=buildname&compare1=61&value1=Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI&field2=groupname&compare2=61&value2=Continuous&field3=buildstarttime&compare3=84&value3=now
and in more detail here:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2827563&filtercount=3&showfilters=1&field1=groupname&compare1=61&value1=Continuous&field2=buildstarttime&compare2=84&value2=now&filtercombine=and
The only commits pulled that CI iteration were commits from you two as shown, for example, here:
* http://testing.sandia.gov/cdash/viewNotes.php?buildid=2827737##note0
The test Teko_DiagonallyScaledPreconditioner_MPI_1 failure at:
* http://testing.sandia.gov/cdash/testDetails.php?test=37874341&build=2827737
shows:
```
4. tDiagonallyScaledPreconditioner_application_test_row_UnitTest ... Teko: Inverse "Amesos" is of type strat prec = 0, strat solv = 1, block prec = 0
Teko: Inverse "ML" is of type strat prec = 1, strat solv = 0, block prec = 0
Error, the parameter {name="refmaxwell: 11list",type="ParameterList",value="..."}
in the parameter (sub)list "ANONYMOUS->Preconditioner Types->ML->ML Settings"
was not found in the list of valid parameters!
```
The other test failure does not show any useful output.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1232Create and publish an official Trilinos User Support Policy2017-09-19T16:55:37ZJames WillenbringCreate and publish an official Trilinos User Support Policy*Created by: maherou*
The user support policy for Trilinos has been implicit from project inception. We need to make an explicit policy. Basic elements are:
- [x] Expectations for the general community.
- [x] Expectations for fund...*Created by: maherou*
The user support policy for Trilinos has been implicit from project inception. We need to make an explicit policy. Basic elements are:
- [x] Expectations for the general community.
- [x] Expectations for funded projects.
- [x] Roles and accountability.
**CC:** @trilinos/frameworkImprove productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1237KokkosKernels CI build failure on 4/12/20172017-04-12T16:26:22ZJames WillenbringKokkosKernels CI build failure on 4/12/2017*Created by: bartlettroscoe*
A KokkosKernels build failure was caught by the standard CI build:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&filtercount=3&showfilters=1&filtercombine=and&field1=buildname&compare1=61&v...*Created by: bartlettroscoe*
A KokkosKernels build failure was caught by the standard CI build:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&filtercount=3&showfilters=1&filtercombine=and&field1=buildname&compare1=61&value1=Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI&field2=groupname&compare2=61&value2=Continuous&field3=buildstarttime&compare3=84&value3=now
in the first CI iteration this morning:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2834087&filtercount=3&showfilters=1&field1=groupname&compare1=61&value1=Continuous&field2=buildstarttime&compare2=84&value2=now&filtercombine=and
(which suggests the checkin-test-sems.sh script should have caught this build failure before the push). But this was only a test/example failure which does not disable KokkosKernels in downstream packages. (Note that we will lose this behavior once we do the single configure, build, and tests https://github.com/TriBITSPub/TriBITS/issues/183 ).
But it looks like @crtrott reacted to this quickly fixed the KokkosKernels in the latest CI build iteration:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2834513&filtercount=3&showfilters=1&field1=groupname&compare1=61&value1=Continuous&field2=buildstarttime&compare2=84&value2=now&filtercombine=and
Note that since this was only a test/example failure for KokkosKernels, this would not have stopped anyone else's pushes using the checkin-test-sems.sh script where were only changing a package downstream from KokkosKernels.
Just added this issue to document this failure since it was interesting for a few reasons:
* The build failure should have likely have been caused by the checkin-test-sems.sh script
* The failure was seen and fixed in the very next CI iteration
* This was only a build failure for examples/tests so this would not have blocked anyone else's push to changes in packages downstream from KokkosKernels
Since Trilinos CDash info is forgotten pretty quickly (just a month or so).
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1246Create initial standard shared build configuration files and scripts for ATDM...2018-01-11T19:18:36ZJames WillenbringCreate initial standard shared build configuration files and scripts for ATDM builds of Trilinos*Created by: bartlettroscoe*
**Description:**
This story is to track the creation of standard build configuration files and scripts for Trilinos on ATDM systems as per the strategy outlined in:
* https://sems.sandia.gov/jira/brows...*Created by: bartlettroscoe*
**Description:**
This story is to track the creation of standard build configuration files and scripts for Trilinos on ATDM systems as per the strategy outlined in:
* https://sems.sandia.gov/jira/browse/TRIL-171
The idea is that ATDM-funded Trilinos Developers, ATDM application developers, ATDM application users, automated builds of Trilinos, and others who build Trilinos on ATDM platforms related to ATDM will use the same set of configuration files and scripts. This will provide a point of collaboration and coordination between all of these people and processes.
**Definition of Done:**
* ToDo: What is the full scope of this story? How many ATDM platforms need be collected into this system before we close this story?
**CC:** @trilinos/framework, @bathmatt, @rppawlo, @kruger
Get Trilinos builds and testing for ATDM under coordinated version controlhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1247Create automated ATDM build of Trilinos on shiller submitting to Trilinos CDa...2018-01-11T19:20:27ZJames WillenbringCreate automated ATDM build of Trilinos on shiller submitting to Trilinos CDash site*Created by: bartlettroscoe*
**Next Action Status:**
Reproduced the configure of Trilinos+Drekar on 'shiller'. Next: Create refactored files and scripts and put into Trilinos git repo ...
**Description:**
This story is assoica...*Created by: bartlettroscoe*
**Next Action Status:**
Reproduced the configure of Trilinos+Drekar on 'shiller'. Next: Create refactored files and scripts and put into Trilinos git repo ...
**Description:**
This story is assoicated with #1246 and that is to drive the creation of these common ATDM configuration files and scripts while getting an automated build of Trilinos for ATDM set up on shiller with CUDA/GPUs. This will be followed by other stories for getting common configuration files and automated builds set up for other ATDM platforms.
These files will be copied and refactored from those that exist for Trilinos+Drekar on shiller. The existing configure scripts in for Trilinos+Drekar will be refactored to use these new scripts so there is no duplication.
**Definition of Done:**
* A set of standard configuration files and scripts exists in the Trilinos git repo to configure Trilinos for ATDM on Shiller
* The Drekar build scripts are refactored to use these.
* An automated nightly build for Trilinos for the packages used by Drekar and EMPIRE is running and posting to the Trilinos CDash site.
**CC:** @trilinos/framework, @bathmatt, @rppawlo, @kruger
Get Trilinos builds and testing for ATDM under coordinated version controlhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1288Trilinos-Xyce testing for C++11=OFF is failing2017-05-08T21:42:41ZJames WillenbringTrilinos-Xyce testing for C++11=OFF is failing*Created by: hkthorn*
@trilinos/framework @jwillenbring @bmpersc It looks like the environment issues with the Trilinos-Xyce testing were fixed, but the nightly testing of this build still does not complete.*Created by: hkthorn*
@trilinos/framework @jwillenbring @bmpersc It looks like the environment issues with the Trilinos-Xyce testing were fixed, but the nightly testing of this build still does not complete.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1294Remove all failures in "Clean" track builds.2017-10-11T13:53:14ZJames WillenbringRemove all failures in "Clean" track builds.*Created by: jwillenbring*
Done for this ticket means all "Clean" track builds shown on
[http://testing.sandia.gov/cdash/index.php?project=Trilinos&date=2017-05-07](http://testing.sandia.gov/cdash/index.php?project=Trilinos&date=201...*Created by: jwillenbring*
Done for this ticket means all "Clean" track builds shown on
[http://testing.sandia.gov/cdash/index.php?project=Trilinos&date=2017-05-07](http://testing.sandia.gov/cdash/index.php?project=Trilinos&date=2017-05-07)
are 100% passing.Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1298Move prototype parameterized tests to main repo2017-05-10T17:29:15ZJames WillenbringMove prototype parameterized tests to main repo*Created by: bmpersc*
The prototype parameterized build has been working well for a while so it is time to move it into the Trilinos repo and update all the builds that are using it to use the Trilinos repo instead of the prototype repo.*Created by: bmpersc*
The prototype parameterized build has been working well for a while so it is time to move it into the Trilinos repo and update all the builds that are using it to use the Trilinos repo instead of the prototype repo.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1304Address basic stability of Trilinos 'develop' branch short-term2018-06-14T14:45:43ZJames WillenbringAddress basic stability of Trilinos 'develop' branch short-term*Created by: bartlettroscoe*
**Related to:** #1362
**Next Action Status:**
The auto PR testing process (#1155) is deployed and is working fairly well to stabilize 'develop' (at least as good or better than the checkin-test-sems....*Created by: bartlettroscoe*
**Related to:** #1362
**Next Action Status:**
The auto PR testing process (#1155) is deployed and is working fairly well to stabilize 'develop' (at least as good or better than the checkin-test-sems.sh script did). Further improvements will be worked in other issues.
**Description:**
This story is to discuss and decide how to address stability problems of the Trilinos 'develop' branch in the short term. I know there is a long-term plan to use a PR model (see #1155) but since there are no updates or ETA on that, we need to address stability issues faster than that.
Currently there have been a good deal of stability problems of the Trilinos 'develop' branch, even with the basic CI build linked to from:
* https://github.com/trilinos/Trilinos/wiki/Policies--%7C-Testing#post_push_ci_testing
and the "Clean" builds shown here:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&display=project&filtercount=2&showfilters=1&filtercombine=and&field1=groupname&compare1=61&value1=Clean&field2=buildstarttime&compare2=84&value2=now
The "Clean" builds have never been clean in the entire history of the track.
Some very recent examples of failures causing this are described in #1290 and #1301. These have broken the standard CI build and the "Clean" builds continuously since May 4 (and it is still broken as I type this).
We need a strategy to improve stability right now. I have been helping people set up to use the [checkin-test-sems.sh](https://github.com/trilinos/Trilinos/wiki/Policies-%7C-Safe-Checkin-Testing) script to test and push their changes. I would estimate that a large percentage of the failures (and 100% of the CI failures) seen on CDash would be avoided by usage of the checkin-test-sems.sh script.
**CC:** @trilinos/framework Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1335checkin-test.py no longer functions2017-06-14T14:15:03ZJames Willenbringcheckin-test.py no longer functions*Created by: csiefer2*
@bartlettroscoe
@bmpersc
The python checkin script no longer functions. It requires yaml_cpp, but cannot find it even if the associated sems module is loaded.*Created by: csiefer2*
@bartlettroscoe
@bmpersc
The python checkin script no longer functions. It requires yaml_cpp, but cannot find it even if the associated sems module is loaded.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1341Eliminate warnings in CI build coming from mpi.h with GCC 4.9.3 and OpenMPI f...2017-06-27T14:51:00ZJames WillenbringEliminate warnings in CI build coming from mpi.h with GCC 4.9.3 and OpenMPI from 1.6.5*Created by: bartlettroscoe*
**Next Action Status:**
Adding `-isystem` for OpenMPI 1.6. include dir makes warnings go away locally but not for CTest -S script. Asked SEMS if they could patch mpi.h file (but unknown when that might h...*Created by: bartlettroscoe*
**Next Action Status:**
Adding `-isystem` for OpenMPI 1.6. include dir makes warnings go away locally but not for CTest -S script. Asked SEMS if they could patch mpi.h file (but unknown when that might happen). Next: Switch CI build to GCC 4.8.4 which does not emit the warnings?
**CC:** @trilinos/framework
**Description:**
With the upgrade to GCC 4.9.3 (see #1002), we are now getting a lot of warnings from OpenMPI 1.6.5 headers like:
```
In file included from /projects/sems/install/rhel6-x86_64/sems/compiler/gcc/4.9.3/openmpi/1.6.5/include/mpi.h:253:0,
from /scratch/rabartl/Trilinos.base/SEMSCIBuild/Trilinos/packages/teuchos/core/src/Teuchos_Time.hpp:56,
from /scratch/rabartl/Trilinos.base/SEMSCIBuild/Trilinos/packages/teuchos/core/src/Teuchos_Time.cpp:45:
/projects/sems/install/rhel6-x86_64/sems/compiler/gcc/4.9.3/openmpi/1.6.5/include/mpi_portable_platform.h:374:34: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
_STRINGIFY(__GNUC__)"."_STRINGIFY(__GNUC_MINOR__)"."_STRINGIFY(__GNUC_PATCHLEVEL__)
^
/projects/sems/install/rhel6-x86_64/sems/compiler/gcc/4.9.3/openmpi/1.6.5/include/mpi_portable_platform.h:374:63: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
_STRINGIFY(__GNUC__)"."_STRINGIFY(__GNUC_MINOR__)"."_STRINGIFY(__GNUC_PATCHLEVEL__)
^
```
such as you see, for example, in this CI iteration:
* http://testing.sandia.gov/cdash/viewBuildError.php?type=1&buildid=2902564
Looking at the new "Clean" build
Linux-gcc-4.9.3-MPI_Release_gcc_4.9.3_openmpi_1.8.7_DEV targeted for SIERRA, for example, at:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2901291
perhaps our CI build should be upgraded to OpenMPI 1.8.7?
In any case, this story is to make these warnings go away so they don't spam Trilinos developers and CDash.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1344How to contribute to wiki pages2017-09-06T19:47:50ZJames WillenbringHow to contribute to wiki pages*Created by: tjfulle*
@bartlettroscoe, how does one contribute to the wiki pages? It don't see a way to fork the wiki so that I can submit a PR. Nor do I see any create new page/edit page buttons. Should I just clone and send a diff ...*Created by: tjfulle*
@bartlettroscoe, how does one contribute to the wiki pages? It don't see a way to fork the wiki so that I can submit a PR. Nor do I see any create new page/edit page buttons. Should I just clone and send a diff to someone?
It seems valuable for new developer, such as myself, to give input to the wiki (at least to the new developer/building Trilinos pages) while the pain of ramping up is fresh on their mind...https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1359TriBITS: application access to TPL_Netcdf_PARALLEL2017-05-24T14:18:26ZJames WillenbringTriBITS: application access to TPL_Netcdf_PARALLEL*Created by: ibaned*
In the Albany application, we would like to be able to detect whether Trilinos was built with the `TPL_Netcdf_PARALLEL` flag `ON`. What is the best way to do that ?
@bartlettroscoe @trilinos/framework*Created by: ibaned*
In the Albany application, we would like to be able to detect whether Trilinos was built with the `TPL_Netcdf_PARALLEL` flag `ON`. What is the best way to do that ?
@bartlettroscoe @trilinos/frameworkhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1363Upgrade minimum support GCC from 4.7.2 with C++11 to something higher (4.8.4 ...2017-06-26T17:00:53ZJames WillenbringUpgrade minimum support GCC from 4.7.2 with C++11 to something higher (4.8.4 or 4.9.3)?*Created by: bartlettroscoe*
**Next Action Status:**
Looks like some customers need GCC 4.8.4 with C++11 Trilinos currently. Next: Decide to make the downgrade the CI server from GCC 4.9.3 back to GCC 4.8.4 (which currently passes t...*Created by: bartlettroscoe*
**Next Action Status:**
Looks like some customers need GCC 4.8.4 with C++11 Trilinos currently. Next: Decide to make the downgrade the CI server from GCC 4.9.3 back to GCC 4.8.4 (which currently passes the full CI test suite) ...
**CC:** @trilinos/framework
**Description:**
Maintaining support for GCC 4.7.2 puts a lot of constraints on the C++11 code that you can write and is holding back Trilinos development (see #1002). This story is to remove testing and support for GCC 4.7.2 and upgrade to GCC 4.8.x or newer (GCC 4.9.3 would be better given that is what Sierra uses).
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1375Remove Phalanx and Panzer from -Werror GCC 4.7.2 build2017-06-01T15:50:11ZJames WillenbringRemove Phalanx and Panzer from -Werror GCC 4.7.2 build*Created by: jwillenbring*
CC: @bartlettroscoe @william76
@rppawlo requested Phalanx and Panzer be removed from the GCC 4.7.2 Werror build. Phalanx and Panzer should be included in the 4.9 build.*Created by: jwillenbring*
CC: @bartlettroscoe @william76
@rppawlo requested Phalanx and Panzer be removed from the GCC 4.7.2 Werror build. Phalanx and Panzer should be included in the 4.9 build.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1378Upgrade Trilinos for replacement of PARSE_ARGUMENTS() in TriBITS (TriBITSPub/...2018-11-13T16:25:04ZJames WillenbringUpgrade Trilinos for replacement of PARSE_ARGUMENTS() in TriBITS (TriBITSPub/TriBITS#181)*Created by: bartlettroscoe*
This story is to track the work to update Trilinos to use an updated version of TriBITS that removes the usage of the home-grown `PARSE_ARGUMENTS()` with the built-in CMake function `CMAKE_PARSE_ARGUMENTS()`...*Created by: bartlettroscoe*
This story is to track the work to update Trilinos to use an updated version of TriBITS that removes the usage of the home-grown `PARSE_ARGUMENTS()` with the built-in CMake function `CMAKE_PARSE_ARGUMENTS()` (see TriBITSPub/TriBITS#181).
When I tried the upgrade, I got a bunch of configure warnings and errors due to stronger checking provided by `CMAKE_PARSE_ARGUMENTS()`.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1386Eliminate unnecessary rebuilds of Trilinos code on a reconfigure2017-06-10T14:48:49ZJames WillenbringEliminate unnecessary rebuilds of Trilinos code on a reconfigure*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @maherou, @rppawlo, @jhux2
**Description:**
It has been reported by several people (and in #1241) that some (or perhaps all) reconfigurations of Trilinos will trigger the ...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @maherou, @rppawlo, @jhux2
**Description:**
It has been reported by several people (and in #1241) that some (or perhaps all) reconfigurations of Trilinos will trigger the rebuild of a **lot** of object files, libraries and executables.
This story is to officially investigate this issue and try to resolve any problems that are discovered.
To help diagnose this, the Ninja build tool should be used since it can be used to trace why the build system triggers the rebuilds of each object file.
Reduce build times for Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1390Create plan to drop Trilinos support for C++98 preventing the usage of C++112017-12-19T23:01:13ZJames WillenbringCreate plan to drop Trilinos support for C++98 preventing the usage of C++11*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/teuchos, @trilinos/thyra, @trilinos/nox, @maherou
**Description:**
The requirement to maintain C++98 support for older packages like Teuchos, Thyra, NOX and othe...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/teuchos, @trilinos/thyra, @trilinos/nox, @maherou
**Description:**
The requirement to maintain C++98 support for older packages like Teuchos, Thyra, NOX and others that are still being developed and need much more development in the near future, is creating a major capability and productivity impediment for projects like ATDM. (For example, the refactoring of Thyra to improve the design, usage, and performance of RTOps will require C++11.) But we can't use C++11 in these packages because there are still some Trilinos customers that still require that these packages build with GCC 4.4.7 and C++11 turned off. And just the usage of `auto` alone will significantly improve the development and maintenance of templated code. (And then there is the performance improvements of using move constructors and assignment operators, etc.)
To address this problem we could either, for example:
1) Require all Trilinos customers to upgrade their compilers to GCC 4.9.3 or newer to allow C++11 to be used in all Trilinos packages from Teuchos on down the dependency chain.
or:
2) Create a fork of Trilinos for C++98 packages needed by these customers and then allow the main Trilinos 'develop' and 'master' branches require C++11 for all packages from Teuchos on down the dependency chain. (This would require the Trilinos development team to continue to provide patches, releases, and address other issues on this fork, so this fork could not be completely static but it should see very little development.)
But eventually every Trilinos customer will have a C++11 compiler so eventually we will be going with option-1 so going with option-2 in the short-term may not be too bad.
Improve productivity, stability, and quality of Trilinos