FAIL: glasgow build --rev C3 uart

[mbparks]

PS C:\Users\plebe> glasgow build --rev C3 uart
I: glasgow.cli: generating bitstream for applet 'uart'
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "C:\Users\plebe\pipx\venvs\glasgow\Scripts\yowasp-yosys.exe\__main__.py", line 7, in <module>
  File "C:\Users\plebe\pipx\venvs\glasgow\Lib\site-packages\yowasp_yosys\__init__.py", line 16, in _run_yosys_argv
    sys.exit(run_yosys(sys.argv[1:]))
             ^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\plebe\pipx\venvs\glasgow\Lib\site-packages\yowasp_yosys\__init__.py", line 11, in run_yosys
    return yowasp_runtime.run_wasm(__package__, "yosys.wasm", resources=["share"],
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\plebe\pipx\venvs\glasgow\Lib\site-packages\yowasp_runtime\__init__.py", line 111, in run_wasm
    store.set_wasi(wasi_cfg)
  File "C:\Users\plebe\pipx\venvs\glasgow\Lib\site-packages\wasmtime\_store.py", line 97, in set_wasi
    raise WasmtimeError._from_ptr(error)
wasmtime._error.WasmtimeError: The system cannot find the path specified. (os error 3)
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "c:\users\plebe\.local\bin\glasgow.exe\__main__.py", line 7, in <module>
  File "C:\Users\plebe\glasgow\software\glasgow\cli.py", line 937, in run_main
    exit(asyncio.run(main()))
         ^^^^^^^^^^^^^^^^^^^
  File "C:\Users\plebe\AppData\Local\Programs\Python\Python312\Lib\asyncio\runners.py", line 194, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "C:\Users\plebe\AppData\Local\Programs\Python\Python312\Lib\asyncio\runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\plebe\AppData\Local\Programs\Python\Python312\Lib\asyncio\base_events.py", line 687, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "C:\Users\plebe\glasgow\software\glasgow\cli.py", line 833, in main
    f.write(plan.get_bitstream())
            ^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\plebe\glasgow\software\glasgow\target\hardware.py", line 171, in get_bitstream
    bitstream_data = self.execute(debug=debug)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\plebe\glasgow\software\glasgow\target\hardware.py", line 145, in execute
    products  = self.lower.execute_local(build_dir, env=environ)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\plebe\pipx\venvs\glasgow\Lib\site-packages\amaranth\build\run.py", line 101, in execute_local
    subprocess.check_call(["cmd", "/c", f"call {self.script}.bat"],
  File "C:\Users\plebe\AppData\Local\Programs\Python\Python312\Lib\subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmd', '/c', 'call build_top.bat']' returned non-zero exit status 1.

Running Win11, and latest Python, pipx and git

[whitequark]

This error is definitely a property of your environment, but it's difficult to say exactly how. The actual error most likely comes from one of these statements, although it is also possible (but unlikely) that either the temporary directory or the resource directory are missing.

Do you happen to have a net use or subst mount defined that is referencing a non-existent target?

[whitequark]

It looks like I just reproduced this in my environment (unintentionally, I was trying to get something done). It has a network share, but no subst mounts.

[whitequark]

I've confirmed that this is an upstream (YoWASP) error and not specific to Glasgow:

[whitequark]

I've confirmed that the culprit is these preopens:

            for letter in "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ":
                wasi_cfg.preopen_dir(letter + ":\\", letter + ":")

Namely, wasmtime used to ignore invalid preopens until you accessed them, but it no longer does since version 20. The workaround for now is to downgrade wasmtime to version 19.0.0.

[whitequark]

This is an upstream issue in the YoWASP runtime and/or Wasmtime, so I filed two issues on it:

• Does not work on Windows with Wasmtime 20 YoWASP/runtime-py#3
• Since Wasmtime 20, preopens of non-existent directories fail eagerly rather than on first access bytecodealliance/wasmtime#8552

There is an automated testsuite that is supposed to prevent this from happening, however unfortunately it does not cover Windows. We could probably run it under Wine...

[whitequark]

I've fixed this in https://pypi.org/manage/project/yowasp-runtime/release/1.55/ and yanked the broken release. You can upgrade the virtual environment, or just reinstall it from scratch if you don't want to bother.