Update env and deps in travis.yml

[CamStan]

This changes how required packages are set up in Travis so they do not fail as part of the before_install stage. Also changes spack setup and gets rid of the external sds-repo since margo is now upstream in spack.

Also, mercury has now been fixed to build internal headers if not using boost. When it needed boost, travis would time out since the build would take too long. Thus this also creates a packages.yml so that spack doesn't build any dependencies that the travis environment already has and take a long time to build (i.e., cmake, perl, etc). This reduces a fresh (nothing in cache) travis build from ±35 minutes to ±10 minutes.

Also updates the docs to account for any related changes to how a user might build.

Note:

These changes required the travis cache be cleared. Other PRs without these changes might time out as they may attempt to build boost. They should pass again once this has been merged.

Description

• Changed how packages are installed to the built-in travis method
• Created a packages.yml to account for dependencies travis already has and to speed up build
• Cleaned up how spack is set up
• Configure with the --enable-fortran option that was added in Add --enable-fortran option #314
• Update build docs

Note for future reference:

In the event that we do want to test with boost enabled for mercury, it can be supplied by the travis environment and added to the packages.yml so that spack doesn't have to build it.

To do this, add a travis trusted boost source (using sourceline: [reference]) under addons: and apt::

addons:
  apt:
    update: true
    sources:
      - sourceline: 'ppa:mhier/libboost-latest'
    packages:
      ⋮

and under packages, add which boost it is:

packages:
  ⋮
  - boost.1.68
  ⋮

Then in the packages.yml, add:

packages:
  ⋮
  boost:
    buildable: False
    paths:
      [email protected]: /usr
  ⋮

Motivation and Context

The sds-repo spack packages are now upstream in spack so we can remove our dependency on that repo.

How Has This Been Tested?

Tested with forked repo's travis (here)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the UnifyCR code style requirements.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• All commit messages are properly formatted.

[MichaelBrim]

Looks good Cameron