Cache: build folders on Windows do not have the same length

[h-vetinari]

I'm seeing a panic for cross-compiling win-arm64 in conda-forge/zlib-feedstock#83:

 │ ╭─ Running cache build
 │ │ Cache key: "d61741a1dfc85070a5d76e16499006b74f9d73aa665a8fc66d38af00b567dd58"
 │ │ Restoring cache from "D:\\bld\\build_cache\\bld_d61741a1dfc85070a5d76e16499006b74f9d73aa665a8fc66d38af00b567dd58"
 │ │ Restoring from cache: "Library\\lib\\zlibwapi.lib"
 │ │ Restoring from cache: "Library\\include\\zconf.h"
 │ │ Restoring from cache: "Library\\lib\\pkgconfig\\zlib.pc"
thread 'main' panicked at src\cache.rs:265:9:
assertion `left == right` failed: Prefixes must have the same length
  left: 46
 right: 49
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
 │ │
 │ ╰─────────────────── (took 0 seconds)
 │
 ╰─────────────────── (took 0 seconds)

ERROR conda.cli.main_run:execute(125): `conda run rattler-build build --recipe recipe -m .ci_support\win_arm64_.yaml --no-test --extra-meta flow_run_id=azure_20240910.4.1 --extra-meta remote_url=*** --extra-meta sha=8fb18c4e5c97f7155954d8c3b4332efce29c083d --experimental` failed. (See above for error)
##[error]Cmd.exe exited with code '101'.

Very likely this is related to / vs. \ vs. \\ and strings which are raw or not.

Speaking of which, I'm also noticing inconsistencies on win-64 w.r.t. the package content:

 │ │ Files in package:
 │ │   - Library\bin\zlib.dll       # \..\      !!!
 │ │   - zlib.dll
 │ │   - info/about.json            # /
 │ │   - info\hash_input.json       # \         !!!
 │ │   - info/index.json            # /
 │ │   - info/licenses/LICENSE      # /../
 │ │   - info/paths.json            # /
 │ │   - info/recipe/[...]          # /../
 │ │   - info/run_exports.json      # /
 │ │   - info/tests\tests.yaml      # /..\      !!!

Not sure if that is related to the test failures I'm seeing on win-64, but it's a plausible candidate IMO.

[wolfv]

Hmm, while the different slashes look weird indeed, I don't think in this case it's the root cause.

We are searching for a given prefix inside a file and store that in a little JSON file that sits in the cache folder. We then basically do what conda does when restoring from a cache and replace all the prefixes. For some reason, it looks like we are storing & replacing a prefix that is longer than the later build prefix.

It might have to do with UNC paths ... but still not sure.

[h-vetinari]

You should be able to take the current state of that zlib PR as a test - it should be buildable on windows in principle AFAIU, and so any failure should boil down to a rattler-build bug

[h-vetinari]

@wolfv, I think this could actually be part of the same cross-compilation confusion that we seem to be running into for osx-arm64.

The difference between 46 and 49 characters would exactly account for the arm between win-64 and win-arm64.

[h-vetinari]

(though independently from getting the right host platform, it would be nice to harmonize the slashes)

[wolfv]

Can we try again with the latest smithy? ah, wait, we need a new release first to fix the cache :)

[wolfv]

After adding the additional logging we can now see:

 │ ╭─ Running cache build
 │ │ Cache key: "854557c81b9cd5f51d993371c6f1bcceaea7b102cc525c18f3e2153fa87403e5"
 │ │ Restoring cache from "D:\\bld\\build_cache\\bld_854557c81b9cd5f51d993371c6f1bcceaea7b102cc525c18f3e2153fa87403e5"
 │ │ Restoring from cache: "Library\\include\\zlib.h"
 │ │ Restoring from cache: "Library\\bin\\zlib.dll"
 │ │ Restoring from cache: "Library\\lib\\z.lib"
 │ │ Restoring from cache: "Library\\lib\\pkgconfig\\zlib.pc"
thread 'main' panicked at src\cache.rs:281:9:
assertion `left == right` failed: Prefixes must have the same length: "D:\\bld\\bld\\rattler-build_libzlib_1727970322\\h_env" != "D:\\bld\\bld\\rattler-build_libzlib-wapi_1727970322\\h_env"
  left: 49
 right: 54
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

So the build folder somehow changes mid-build. Interesting!

[wolfv]

Ah ok, this is interesting. On Unix we make sure that the paths are always the same length by adding more or less "placeholder" statements. On Windows we are not doing that. This is apparently not good for the logic, but we are also not supposed to do any binary replacements on Windows either (so the actual length of the placeholder doesn't really matter that much).

So we could relax this constraint for Windows.

[h-vetinari]

How is the build folder change related to the number of placeholder characters? 🤔 The core change is between build_libzlib and build_libzlib-wapi in the respective environment paths, AFAICT.

[wolfv]

On Unix this would read rattler-build_libzlib_1727970322/h_env_placeholder_placehol... (up to a deterministic number of characters).

On Windows, it's different.

On Unix the length of this prefix does not change irregardless the number of characters that the package name has, so it never fails on this assert.

[h-vetinari]

Ah okay, so the change of path is expected, but the assert is wrong. Interesting too that this only seems to trigger in cross compilation.

In any case, thanks for getting to the bottom of this!