Compliance with xSDK v0.3 policies

[aprokop]

The xSDK draft community policies are available here.

As of draft version 0.3 (as of December 2016), these policies are:

• M1. Each xSDK-compatible package must support either the standard GNU Autoconf or CMake
  options
• M2. Each xSDK-compatible package must provide a comprehensive test suite that can be run by
  users and does not require the purchase of commercial software.
• M3. Each xSDK-compatible package that utilizes MPI must restrict its MPI operations to MPI
  communicators that are provided to it and not use directly MPI_COMM_WORLD.
• M4. Each package team must do a “best effort” at portability to key architectures , including
  standard Linux distributions, GNU, Clang, vendor compilers, and target machines 4 at ALCF, NERSC, OLCF.
• M5. Each package team must provide a documented, reliable way to contact the development
  team; mode of contact may be by email or a website.
• M6. Each package should respect the decisions made by other previously called packages
  regarding system resources and settings.
• M7. The package source code must come with an open source license , for example, one of the OSI listed licenses.
• M8. Each package must provide a runtime API , for example a function call, to return the current
  version number of the software.
• M9. Each package should use a limited and well-defined symbol, macro, library, and include file
  name space.
• M10. It is mandatory that each package have an IDEAS accessible repository (not necessarily
  publicly available), where the development version of the package is available.
• M11. No package should have hardwired print or I/O statements that cannot be turned off through a programmatic interface; output should never be hard-wired to stdout or stderr.
• M12. If a package imports software that is externally developed and maintained, then it must allow
  installing, building, and linking against an outside copy of that software.
• M13 : When configured with a prefix a package must install its headers and libraries under
  /include/ and /lib/, respectively.
• M14: All xSDK-compatible packages must be buildable using 64 bit pointers (this is commonly the
  default).
• R1. It is recommended that each package have a public repository , for example at GitHub or
  Bitbucket, where the development version of the package is available.
• R2. It is recommend that all packages make it possible to run their test suite under valgrind in order to test for memory corruption issues.
• R3. It is recommended that each package adopt and document a consistent system for
  propagating/returning error conditions/exceptions and provide an API for changing the behavior.
• R4. It is recommended that each package free all system resources it has acquired as soon as
  they are no longer needed.
• R5. It is recommended that each package provide a mechanism to export its ordered list of library
  dependencies so that any other package or executable linking to the package knows to include these dependencies when linking.

[aprokop]

Some comments:

• M4 I don't know we are portable at the moment, as we have not tried compiling using platform compilers.
• M8 Not sure if we want to return the same version of Trilinos or now. This is related to Switch branches for release #151.
• M9 Requires a bit of work
  • Installation
    Right now, we install FortranTestMarcros.h, FortranTestUtilities.h, DBCF.h. We no longer install the testing utilities files. The name forerror is also quite generic, I think.~
  • Namespace naming
    We need to move CHECK_IERR out of testing macros to ForTrilinos.h and namespace it somehow.
  • Global variable pollution
    Some ideas (about global errors) are in Rename ierr and serr #167.
  • Enum namespaces
    Needs fixing, see Automatically prefix enum names #177
• M11 need to check.
  Would this require interaction with FancyOStream? If yes, we are in a deep hole.
• M12 We really need SWIG only for the DeveloperMode so I'm not sure that counts. We a) do not import SWIG in any scenario, and b) it is transparent for users, so the point is moot.
• M13 I assume that's true but need to check. Checked, we correctly install in include/ and lib/.
• R3 We have a system in place, but not the API to change the behavior. Our system is also slightly inconsistent as we may both return an error, and throw an exception (if there is already a pending error that has not been reset).
• R4 Most likely OK.