forked from spack/spack
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
llnl.util.filesystem: multiple entrypoints and max_depth (spack#47495)
If a package `foo` doesn't implement `libs`, the default was to search recursively for `libfoo` whenever asking for `spec[foo].libs` (this also happens automatically if a package includes `foo` as a link dependency). This can lead to some strange behavior: 1. A package that is normally used as a build dependency (e.g. `cmake` at one point) is referenced like `depends_on(cmake)` which leads to a fully-recursive search for `libcmake` (this can take "forever" when CMake is registered as an external with a prefix like `/usr`, particularly on NFS mounts). 2. A similar hang can occur if a package is registered as an external with an incorrect prefix - [x] Update the default library search to stop after a maximum depth (by default, search the root prefix and each directory in it, but no lower). - [x] The following is a list of known changes to `find` compared to `develop`: 1. Matching directories are no longer returned -- `find` consistently only finds non-dirs, even at `max_depth` 2. Symlinked directories are followed (needed to support max_depth) 3. `find(..., "dir/*.txt")` is allowed, for finding files inside certain dirs. These "complex" patterns are delegated to `glob`, like they are on `develop`. 4. `root` and `files` arguments both support generic sequences, and `root` allows both `str` and `path` types. This allows us to specify multiple entry points to `find`. --------- Co-authored-by: Peter Scheibel <scheibel1@llnl.gov>
- Loading branch information
Showing
7 changed files
with
457 additions
and
113 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.