Both floating-point and NEON are required in all standard ARMv8
implementations. Theoretically though specialized markets can support
no NEON or floating-point at all. Source:
https://developer.arm.com/docs/den0024/latest/aarch64-floating-point-and-neon
On the other hand the base procedure call standard for Aarch64
"assumes the availability of the vector registers for passing
floating-point and SIMD arguments". Further "the Arm 64-bit
architecture defines two mandatory register banks: a general-purpose
register bank which can be used for scalar integer processing and
pointer arithmetic; and a SIMD and Floating-Point register bank".
Source:
https://developer.arm.com/docs/ihi0055/latest/procedure-call-standard-for-the-arm-64-bit-architecture
This makes customization of Aarch64 with no NEON instruction set
available so unlikely that we can consider them a feature of the
generic family.
* py-line-profiler: add 2.1.2, re-run cython if needed
See rkern/line_profiler#166.
* Update var/spack/repos/builtin/packages/py-line-profiler/package.py
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
* Addition of 1.1.3 and 1.1.4
* Addition of conditional enum-34 installation.
* Update var/spack/repos/builtin/packages/py-maestrowf/package.py
Addition of versioning for pyyaml.
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
* Addition of enum34 back to older versions 1.1.3 and below.
* adjust building of OpenFOAM 1806 and earlier
- spack now unpacks into spack-src, but earlier OpenFOAM versions
still expect particular directory names (eg, OpenFOAM-v1806).
Resolve by creating a symlink during patching.
* replace openfoam 1806 patch with URL version
This PR adds a 'concretize' entry to an environment's spec.yaml file
which controls how user specs are concretized. By default it is
set to 'separately' which means that each spec added by the user is
concretized separately (the behavior of environments before this PR).
If set to 'together', the environment will concretize all of the
added user specs together; this means that all specs and their
dependencies will be consistent with each other (for example, a
user could develop code linked against the set of libraries in the
environment without conflicts).
If the environment was previously concretized, this will re-concretize
all specs, in which case previously-installed specs may no longer be
used by the environment (in this sense, adding a new spec to an
environment with 'concretize: together' can be significantly more
expensive).
The 'concretize: together' setting is not compatible with Spec
matrices; this PR adds a check to look for multiple instances of the
same package added to the environment and fails early when
'concretize: together' is set (to avoid confusing messages about
conflicts later on).
