* update globalarrays package to current releases
* rename class to Globalarrays to match package folder
* rename bytes to int64, minor cleanup of descriptions
* int64 False by default
* remove reference to external as we aren't supplying paths, and use args.append()
* correcting args.append syntax
* add conflicts
* Fix bug; don't know why this ever worked in the first place.
* Add fix to netcdf-fortran too; flake8
* Simplify configure_args()
* netcdf-fortran: simplify that too
- there were some leftover spack.* names being used after we removed
globals and moved everything in the top-level namespace to spack.pkgkit
- point those references to their new homes
- remove most `import spack` statements, except for files that need
`spack_version`
- import spack is no longer sufficient to use submodules
(e.g. spack.directives).
- these submodules must be imported directly. Update references
accordingly.
- Spack packages were originally expected to call `from spack import *`
themselves, but it has become difficult to manage imports in the
Spack core.
- the top-level namespace polluted by package symbols, and it's not
possible to avoid circular dependencies and unnecessary module loads in
the core, given all the stuff the packages need.
- This makes the top-level `spack` package essentially empty, save for a
version tuple and a version string, and `from spack import *` is now
essentially a no-op.
- The common routines and directives that packages need are now in
`spack.pkgkit`, and the import system forces packages to automatically
include this so that old packages that call `from spack import *`
will continue to work without modification.
- Since `from spack import *` is no longer required, we could consider
removing ``from spack import *`` from packages in the future and
shifting to ``from spack.pkgkit import *``, but we can wait a while to
do this.
* Use libs[0] and headers.directories[0] instead of hardcoded paths in opencv dependencies
* Fix library finding in libjpeg-turbo
* Use build_type=Debug instead of +debug to determine build_type
- spack.util.lock behaves the same as llnl.util.lock, but Lock._lock and
Lock._unlock do nothing.
- can be disabled with a control variable.
- configuration options can enable/disable locking:
- `locks` option in spack configuration controls whether Spack will use filesystem locks or not.
- `-l` and `-L` command-line options can force-disable or force-enable locking.
- Spack will check for group- and world-writability before disabling
locks, and it will not allow a group- or world-writable instance to
have locks disabled.
- update documentation
Spack doesn't have a CSharp package, so the only time ANTLR would
succeed is if a system-installed CSharp was available. This disables
CSharp support, which enables building on systems without
system-installed CSharp.
