summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-10-04cc: convert compiler wrapper to posix shellTodd Gamblin2-292/+434
This converts everything in cc to POSIX sh, except for the parts currently handled with bash arrays. Tests are still passing. This version tries to be as straightforward as possible. Specifically, most conversions are kept simple -- convert ifs to ifs, handle indirect expansion the way we do in `setup-env.sh`, only mess with the logic in `cc`, and don't mess with the python code at all. The big refactor is for arrays. We can't rely on bash's nice arrays and be ignorant of separators anymore. So: 1. To avoid complicated separator logic, there are three types of lists. They are: * `$lsep`-separated lists, which end with `_list`. `lsep` is customizable, but we picked `^G` (alarm bell) for `$lsep` because it's ASCII and it's unlikely that it would actually appear in any arguments. If we need to get fancier (and I will lose faith in the world if we do) then we could consider XON or XOFF. * `:`-separated directory lists, which end with `_dirs`, `_DIRS`, `PATH`, or `PATHS` * Whitespace-separated lists (like flags), which can have any other name. Whitespace and colon-separated lists come with the territory with PATHs from env vars and lists of flags. `^G` separated lists are what we use for most internal variables, b/c it's more likely to work. 2. To avoid subshells, use a bunch of functions that do dirty `eval` stuff instead. This adds 3 functions to deal with lists: * `append LISTNAME ELEMENT [SEP]` will put `ELEMENT` at the end of the list called `LISTNAME`. You can optionally say what separator you expect to use. Note that we are taking advantage of everything being global and passing lists by name. * `prepend LISTNAME ELEMENT [SEP]` like append, but puts `ELEMENT` at the start of `LISTNAME` * `extend LISTNAME1 LISTNAME2 [PREFIX]` appends everything in LISTNAME2 to LISTNAME1, and optionally prepends `PREFIX` to every element (this is useful for things like `-I`, `-isystem `, etc. * `preextend LISTNAME1 LISTNAME2 [PREFIX]` prepends everything in LISTNAME2 to LISTNAME1 in order, and optionally prepends `PREFIX` to every element. The routines determine the separator for each argument by its name, so we don't have to pass around separators everywhere. Amazingly, as long as you do not expand variables' values within an `eval` environment, you can do all this and still preserve quoting. When iterating over lists, the user of this API still has to set and unset `IFS` properly. We ended up having to ignore shellcheck SC2034 (unused variable), because using evals all over the place means that shellcheck doesn't notice that our list variables are actually used. So far this is looking pretty good. I took the most complex unit test I could find (which runs a sample link line) and ran the same command line 200 times in a shell script. Times are roughly as follows: For this invocation: ```console $ bash -c 'time (for i in `seq 1 200`; do ~/test_cc.sh > /dev/null; done)' ``` I get the following performance numbers (the listed shells are what I put in `cc`'s shebang): **Original** * Old version of `cc` with arrays and `bash v3.2.57` (macOS builtin): `4.462s` (`.022s` / call) * Old version of `cc` with arrays and `bash v5.1.8` (Homebrew): `3.267s` (`.016s` / call) **Using many subshells (#26408)** * with `bash v3.2.57`: `25.302s` (`.127s` / call) * with `bash v5.1.8`: `27.801s` (`.139s` / call) * with `dash`: `15.302s` (`.077s` / call) This version didn't seem to work with zsh. **This PR (no subshells)** * with `bash v3.2.57`: `4.973s` (`.025s` / call) * with `bash v5.1.8`: `4.984s` (`.025s` / call) * with `zsh`: `2.995s` (`.015s` / call) * with `dash`: `1.890s` (`.0095s` / call) Dash, with the new posix design, is easily the winner. So there are several interesting things to note here: 1. Running the posix version in `bash` is slower than using `bash` arrays. That is to be expected because it's doing a bunch of string processing where it likely did not have to before, at least in `bash`. 2. `zsh`, at least on macOS, is significantly faster than the ancient `bash` they ship with the system. Using `zsh` with the new version also makes the posix wrappers faster than `develop`. So it's worth preferring `zsh` if we have it. I suppose we should also try this with newer `bash` on Linux. 3. `bash v5.1.8` seems to be significantly faster than the old system `bash v3.2.57` for arrays. For straight POSIX stuff, it's a little slower. It did not seem to matter whether `--posix` was used. 4. `dash` is way faster than `bash` or `zsh`, so the real payoff just comes from being able to use it. I am not sure if that is mostly startup time, but it's significant. `dash` is ~2.4x faster than the original `bash` with arrays. So, doing a lot of string stuff is slower than arrays, but converting to posix seems worth it to be able to exploit `dash`. - [x] Convert all but array-related portions to sh - [x] Fix basic shellcheck issues. - [x] Convert arrays to use a few convenience functions: `append` and `extend` - [x] Get `cc` tests passing. - [x] Add `cc` tests where needed passing. - [x] Benchmarking. Co-authored-by: Tom Scogland <scogland1@llnl.gov> Co-authored-by: Danny McClanahan <1305167+cosmicexplorer@users.noreply.github.com>
2021-10-04.gitignore needs to be below env and ENV for case-insensitive FSTodd Gamblin1-1/+1
2021-10-04Add 5.2.0 (#26481)haralmha1-0/+1
2021-10-05log4cxx: new version and fix for c++11 (#26480)Martin Pokorny1-1/+8
* Add version 0.12.1 * Add variant to build with C++11 standard build with c++11 standard requires boost threads, and needs explicit setting of CMAKE_CXX_STANDARD
2021-10-04intel-tbb: install pkgconfig file (#23977)KoyamaSohei1-0/+20
* intel-tbb: install pkgconfig file * intel-tbb: install pkgconfig file when @:2021.2.0 * intel-tbb: add blank line * intel-tbb: fix library name to refer * intel-tbb: fix library name to refer again * intel-tbb: use self.prefix.lib.pkgconfig
2021-10-04Stand-alone tests: distinguish NO-TESTS from PASSED (#25880)Tamara Dahlgren2-2/+31
Co-authored-by: Seth R. Johnson <johnsonsr@ornl.gov>
2021-10-04esys-particle: add new package esys-particle (#25338)snehring1-0/+39
* esys-particle: add new package esys-particle * esys-particle: requested changes * esys-particle: placating isort
2021-10-04gcc: apply nvcc patch to more versions (#24295)Daniel Ahlin1-1/+4
Apply to all known affected versions (10.1.0 to 10.3.0 and 11.1.0)
2021-10-04git: new version 2.29.2 (#26478)haralmha1-0/+5
2021-10-04Add new pythia8 variants and fix url_for_version (#26280)iarspider1-30/+75
* Add new pythia8 variants Add proper description to the existing ones * Flake-8 * Flake-8 * Style * Fix Pythia8 recipe * Fix typo in variant description * Update package.py
2021-10-04cppgsl: new version 3.1.0 (#26477)haralmha1-0/+1
2021-10-04py-scikit-learn: add 0.19.2 and 0.22.2.post1 (#26473)Manuela Kuhn1-0/+2
2021-10-04masurca: Fix build with glibc-2.32+ (#26173)snehring1-0/+2
remove sysctl.h which is not used by the build
2021-10-04Avoid replacing symlinked spack.yaml when concretizing an environment (#26428)Pedro Demarchi Gomes2-1/+20
2021-10-04use umpire version 5.0.1:5 (#26451)Pedro Demarchi Gomes1-3/+4
2021-10-04paraview: add v5.10.0-RC1 release (#26291)Vicente Bolea1-0/+1
2021-10-04octave: add support for MKL (#25952)mcuma1-4/+14
2021-10-04grpc: update recipe (#25261)iarspider1-4/+9
1) forward `+shared` to re2 2) add `cxxstd` variant 3) use "more idiomatic" way of setting CMake options
2021-10-04Improve an error message in stage.py (#23737)Andreas Baumbach1-1/+2
2021-10-04cp2k: bugfix for intel oneapi (#26143)Tiziano Müller1-5/+36
2021-10-04arm: added download and better detection (#25460)Oliver Perks1-15/+92
2021-10-04gnupg: Add version 1 (#23798)Harmen Stoppels1-17/+45
From the gnupg.org website: > GnuPG 1.4 is the old, single binary version which still support the > unsafe PGP-2 keys. However, it lacks many modern features and will > receive only important updates. I'm starting to appreciate gpg1 more, because it is relocatable (gng2 has hard-coded paths to gpg-agent and other tools) and it does not require gpg-agent at all.
2021-10-04evtgen: fix mac build and version 2.0.0 with pythia >= 8.304. (#25933)iarspider2-0/+50
2021-10-04py-duecredit: add v0.6.5 (#26465)Manuela Kuhn1-2/+3
2021-10-04py-nibabel: add v2.4.1 (#26462)Manuela Kuhn1-3/+7
2021-10-04podio: remove build_type variant (provided by base package class already) ↵Valentin Volkl1-4/+0
(#26463)
2021-10-04freebayes: Fix running the testsuite and add pkgconfig (#26440)Bernhard Kaindl1-0/+20
freebayes needs the tools of the vcflib it includes to run tests
2021-10-04graph500: added option -fcommon for gcc@10.2 (#25367)Nikolay Simakov1-0/+9
* graph500: added option -fcommon for gcc@10.2:, otherwise failed to build with "multiple definition of `column'" * graph500: moved setting cflag to flag_handler
2021-10-04libunwind: add variants (#26099)iarspider1-10/+44
2021-10-04py-pybids: add v0.9.5 (#26461)Manuela Kuhn1-3/+6
2021-10-04Disable tests on hip for cmake 3.21 (#26460)Harmen Stoppels1-1/+1
2021-10-04py-mne: add new package (#26446)Manuela Kuhn1-0/+27
2021-10-04py-sphinxcontrib-napoleon: add new package (#26457)Manuela Kuhn1-0/+19
2021-10-04py-templateflow: add new package (#26458)Manuela Kuhn1-0/+23
2021-10-04Fix NonVirtualInHierarchyError message format (#26008)Dylan Simon1-1/+1
2021-10-04hdf5: allow implicit functions on apple-clang (#26409)Seth R. Johnson1-7/+7
Work around issues in older hdf5 build and overzealous build flags: ``` >> 1420 /var/folders/j4/fznvdyhx4875h6fhkqjn2kdr4jvyqd/T/9te/spack-stage/spack-stage-hdf5-1.10.4-feyl6tz6hpx5kl7m33avpuacwje2ubul/spack-src/src/H5Odeprec.c:141:8: error: implicit decl aration of function 'H5CX_set_apl' is invalid in C99 [-Werror,-Wimplicit-function-declaration] ```
2021-10-04python: correctly disable ~tkinter when @3.8 (#26365)Seth R. Johnson2-0/+15
The older patch does not apply so the build ends up failing: ``` 1539 In file included from /private/var/folders/fy/x2xtwh1n7fn0_0q2kk29xkv9vvmbqb/T/s3j/spack-stage/spack-stage-python-3.8.11 -6jyb6sxztfs6fw26xdbc3ktmbtut3ypr/spack-src/Modules/_tkinter.c:48: >> 1540 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tk.h:86:11: f atal error: 'X11/Xlib.h' file not found 1541 # include <X11/Xlib.h> 1542 ^~~~~~~~~~~~ 1543 1 error generated. ```
2021-10-04Update byacc (#25837)iarspider1-3/+4
Co-authored-by: Bernhard Kaindl <43588962+bernhardkaindl@users.noreply.github.com>
2021-10-04papi: new variants rocm and rocm_smi (#26214)G-Ragghianti1-6/+27
2021-10-04git-annex: add 8.20210804 for amd64 (#26449)Manuela Kuhn1-2/+11
2021-10-04py-pockets: add new package (#26452)Manuela Kuhn1-0/+18
2021-10-04Build ppc64le docker images (#26442)Massimiliano Culpo4-10/+37
* Update archspec * Add ppc64le to docker images
2021-10-04Update Spec.full_hash docstring (#26456)Massimiliano Culpo1-4/+1
The docstring is outdated since #21735 when the build hash has been included in the full hash.
2021-10-04FEniCSx: fix CMake root directory and dependency versions (#26445)Garth N. Wells3-6/+7
2021-10-04py-seaborn: add v0.11.2 (#26447)Manuela Kuhn1-0/+1
2021-10-04py-transforms3d: add new package (#26448)Manuela Kuhn1-0/+17
2021-10-04ocaml: add v4.13.1 (#26453)Joseph Wang1-1/+1
This is needed in order to make it work with glibc-2.34
2021-10-03ArborX: Explicitly set path to Kokkos (#26347)Daniel Arndt1-5/+4
* Explicitly set path to Kokkos for ArborX testing * Improve formatting * Update var/spack/repos/builtin/packages/arborx/package.py Co-authored-by: Seth R. Johnson <johnsonsr@ornl.gov> * Remove blank line Co-authored-by: Seth R. Johnson <johnsonsr@ornl.gov>
2021-10-03source-highlight: add gcc11 patch (#26412)Hector1-1/+6
2021-10-03PICSAR: added support for GCC >10.0 and arm compiler (#24927)Lorién López Villellas1-0/+8
* -fallow-argument-mismatch flag added when compiling with GCC to avoid a compilation error when using a GCC version > 10.0. Co-authored-by: Haz99 <jsalamerosanz@gmail.com> * Filtered every occurrence of "!$OMP SIMD SAFELEN(LVEC2)" when compiling with nvhcp to avoid a compilation error. Co-authored-by: Haz99 <jsalamerosanz@gmail.com> * Line with more than 80 characters split into multiple lines. Co-authored-by: Haz99 <jsalamerosanz@gmail.com>