summaryrefslogtreecommitdiff
path: root/lib/spack/llnl/util/symlink.py
AgeCommit message (Collapse)AuthorFilesLines
2024-01-02Update copyright year to 2024 (#41919)Todd Gamblin1-1/+1
It was time to run `spack license update-copyright-year` again.
2023-09-28Partial removal of circular dependencies between `spack` and `llnl` (#40090)Massimiliano Culpo1-3/+2
Modifications: - [x] Move `spack.util.string` to `llnl.string` - [x] Remove dependency of `llnl` on `spack.error` - [x] Move path of `spack.util.path` to `llnl.path` - [x] Move `spack.util.environment.get_host_*` to `spack.spec`
2023-09-15Windows RPATHing: fix symlink error (#39933)John W. Parent1-4/+10
With 349ba83, you cannot symlink() if the link already exists. Update the simulated RPATHing logic on Windows to account for that.
2023-08-25Windows symlinking support (#38599)James Smillie1-58/+281
This reapplies 66f7540, which adds supports for hardlinks/junctions on Windows systems where developer mode is not enabled. The commit was reverted on account of multiple issues: * Checks added to prevent dangling symlinks were interfering with existing CI builds on Linux (i.e. builds that otherwise succeed were failing for creating dangling symlinks). * The logic also updated symlinking to perform redirection of relative paths, which lead to malformed symlinks. This commit fixes these issues.
2023-06-27Revert "Updates to symlinking for Windows (#34701)" (#38578)Harmen Stoppels1-278/+58
This reverts commit 66f75407d136c0c06ed01774d5815728afba35ca.
2023-06-26Updates to symlinking for Windows (#34701)David Alexander1-58/+278
* Support hardlinks/junctions on Windows systems without developer mode enabled * Generally, use of llnl.util.symlink.symlink is preferred over os.symlink since it handles this automatically * Generally an error is now reported if a user attempts to create a symlink to a file that does not exist (this was previously allowed on Linux/Mac). * One exception to this: when Spack installs files from the source into their final prefix, dangling symlinks are allowed (on Linux/Mac - Windows does not allow this in any circumstance). The intent behind this is to avoid generating failures for installations on Linux/Mac that were succeeding before. * Because Windows is strict about forbidding dangling symlinks, `traverse_tree` has been updated to skip creating symlinks if they would point to a file that is ignored. This check is not transitive (i.e., a symlink to a symlink to an ignored file would not be caught appropriately) * Relocate function: resolve_link_target_relative_to_the_link (this is not otherwise modified) Co-authored-by: jamessmillie <smillie@txcorp.com>
2023-03-17Windows: properly handle symlink failures (#36003)John W. Parent1-3/+9
In the Windows filesystem logic for creating a symlink, we intend to fall back to a copy when the symlink cannot be created (for some configuration settings on Windows it is not possible for the user to create a symlink). It turns out we were overly-broad in which exceptions lead to this fallback, and the subsequent copy would also fail: at least one case where this occurred is when we attempted to create a symlink that already existed. The updated logic expressly avoids falling back to a copy when the file/symlink already exists.
2023-03-05windows: use `sys.platform == "win32"` instead of `is_windows` (#35640)Todd Gamblin1-6/+4
`mypy` only understands `sys.platform == "win32"`, not indirect assignments of that value to things like `is_windows`. If we don't use the accepted platform checks, `mypy` registers many Windows-only symbols as not present on Linux, when it should skip the checks for platform-specific code.
2023-01-18license year bump (#34921)Harmen Stoppels1-1/+1
* license bump year * fix black issues of modified files * mypy * fix 2021 -> 2023
2022-12-06Avoid stat call in `llnl.util.symlink` on non-windows (#34321)Harmen Stoppels1-1/+4
2022-11-22Windows: add registry query and SDK/WDK packages (#33021)John W. Parent1-1/+1
* Add a WindowsRegistryView class, which can query for existing package installations on Windows. This is particularly important because some Windows packages (including those added here) do not allow two simultaneous installs, and this can be queried in order to provide a clear error message. * Consolidate external path detection logic for Windows into WindowsKitExternalPaths and WindowsCompilerExternalPaths objects. * Add external-only packages win-sdk and wgl * Add win-wdk (including external detection) which depends on win-sdk * Replace prior msmpi implementation with a source-based install (depends on win-wdk). This install can control the install destination (unlike the binary installation). * Update MSVC compiler to choose vcvars based on win-sdk dependency * Provide "msbuild" module-level variable to packages during build * When creating symlinks on Windows, need to explicitly specify when a symlink target is a directory * executables_in_path no-longer defaults to using PATH (this is now expected to be taken care of by the caller)
2022-07-31black: reformat entire repository with blackTodd Gamblin1-8/+8
2022-03-31Windows Support: Fixup Perl build (#29711)John W. Parent1-12/+4
* Add pl2bat to PATH: Windows on Perl requires the script pl2bat.bat and Perl to be available to the installer via the PATH. The build and dependent environments of Perl on Windows have the install prefix bin added to the PATH. * symlink with win32file module instead of using Executable to call mklink (mklink is a shell function and so is not accessible in this manner).
2022-03-17"spack commands --update-completion"John Parent1-30/+11
2022-03-17Windows: Symlink supportBetsy McPhail1-0/+139
To provide Windows-compatible functionality, spack code should use llnl.util.symlink instead of os.symlink. On non-Windows platforms and on Windows where supported, os.symlink will still be used. Use junctions when symlinks aren't supported on Windows (#22583) Support islink for junctions (#24182) Windows: Update llnl/util/filesystem * Use '/' as path separator on Windows. * Recognizing that Windows paths start with '<Letter>:/' instead of '/' Co-authored-by: lou.lawrence@kitware.com <lou.lawrence@kitware.com> Co-authored-by: John Parent <john.parent@kitware.com>