[ScottTodd]

Progress on #827.

This replaces symlinks in the _rocm_sdk_devel folder of a Python install on Windows with hardlinks. Symlinks are not supported in Python wheels (see https://pep-previews--3786.org.readthedocs.build/pep-0778/ for a proposal to change that) so we expand a directory structure containing symlinks from a tarfile on demand. However, Windows has patchy support for symlinks (dependent on registry/policy settings), while hardlinks are more broadly available. For more background information on symlinks vs hardlinks, see https://stackoverflow.com/questions/185899/what-is-the-difference-between-a-symbolic-link-and-a-hard-link .

Tested:

• Locally on my gfx1100 machine with a source build

  # Build
  python .\build_tools\build_python_packages.py --artifact-dir=D:\projects\TheRock\build/artifacts --dest-dir=D:\projects\TheRock\build/packages --version=7.0.0.dev0
  
  # Generate local index for easy installation (one time)
  pip install piprepo
  piprepo build %HOME%/.therock/packages/dist
  
  # Install, overwriting existing
  pip install rocm[libraries,devel]==7.0.0.dev0 --extra-index-url D:\projects\TheRock\build\packages\dist\simple --force-reinstall --no-cache-dir
  
  # Test
  rocm-sdk test

• On CI to build a "dev" release: https://github.com/ROCm/TheRock/actions/runs/16177150195

• On my gfx1151 machine with that dev release

  python -m pip install --index-url https://d25kgig7rdsyks.cloudfront.net/v2/gfx1151/ rocm[libraries,devel]==7.0.0.dev0+98ed4ad77f79822694ec01a36180ec3b95f4bd00
  
  rocm-sdk test

• On CI with a PyTorch wheel build using that dev release (based on a branch with workflow changes): https://github.com/ROCm/TheRock/actions/runs/16179933739/job/45673986615

[stellaraccident]

Some day I would still love a root cause, but I agree this is likely the least bad option. It does create some possibilities of different failure modes on windows vs linux with respect to canonical paths and such: the end result will be that linux will be more strict with respect to package layering and windows will be more permissive. So in the future, we may see layering issues only on the one OS. If it has to be that way, having Linux be the canary is better, given that Windows is so sensitive and hard to debug anyway.