This reverts a change made in #20639 to have GitHub recognize our
ASP files as Prolog, the closest langauge supported by
[Linguist](https://github.com/github-linguist/linguist) at the time.
Linguist has since
[added support for ASP](https://github.com/github-linguist/linguist/pull/7184),
so we no longer need to force Prolog detection -- our `.lp` files should
be auto-detected as ASP.
Signed-off-by: Todd Gamblin <tgamblin@llnl.gov>
The second change technically affects non-Windows, but the
behavior should be exactly the same:
* Packages no longer have access to `.msbuild` and `.nmake`
automatically; they now get them via a dependency on `msvc`.
* Update two CMake-based packages that call `make test` to
instead call `ctest` (`netcdf-cxx4` and `pegtl`).
CMake-based packages should do this because on Windows
`make test` will not generally work, but `ctest` does.
* Fix `openssl` "make test" on Windows (WRT prior point: not
a CMake-based package).
* genfit: depend on c compiler to fix installation issues
genfit does not specify `LANGUAGES` in their `project` declaration yet, so C is also required to pass the cmake stage.
* vbfnlo: Depend on C compiler to pass configure stage
* cppunit: Depend on C compiler to pass configure stage
* Make py-pyqt5 depend on C to fix build error
* bdsim: Depend on C to pass configure stage
This strong preference fixes a sporadic issue when
concretizing environments with `unify:when_possible`.
In the first round of concretization, it is almost
certain that glibc is installed, and that spec might
provide iconv.
In later rounds using that as a provider might be
preferred, as it leads to less nodes to be "built".
To avoid duplication by default, prefer libiconv
in a stronger way than default preferences.
Signed-off-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
Show progress meter for fetches when `stdout` is a `tty`.
* fetch_strategy.py: show progress
* "Fetched: x MB at y MB/s"
* add tests, show % if content-length
This PR fixes the issues with `%` and reused specs, due to https://github.com/spack/spack/issues/49847#issuecomment-2774640234
It does so by adding another layer of indirection, so that whenever a spec
`foo %bar` is encountered, the `%bar` part is encoded as an
`attr("build_requirement", ...)`.
Then:
1. If `foo` is a node to be built, then the build requirement implies a dependency
2. Otherwise it implies looking e.g. reused specs metadata, and ensure it matches
---------
Signed-off-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
When the solver produces specs that do not satisfy the input
constraints, dump both input and output specs as json in an temporary
dir and ask the user to upload these files in a bug report.
