danielamadori commented on issue #822:
URL: https://github.com/apache/tvm-ffi/issues/822#issuecomment-5860629702
Three additions that did not make the first pass.
### The generated line, with both `-Xcompiler` groups
This is what `_generate_ninja_build` produces on Windows once (1) is fixed
locally and the caller appends its own standard, and it shows (2) concretely —
`nvcc` puts its own `-std=c++20` on the host line first, then each `-Xcompiler`
group in order, so the **last** `/std:` wins:
```
-Xcompiler /std:c++17,/O2 -std=c++20 -O3 --expt-relaxed-constexpr
-Xcompiler /std:c++20,/Zc:__cplusplus
-gencode=arch=compute_86,code=compute_86 ...
```
Without the second group, `<source_location>` fails with `C2039` even though
`-std=c++20` is on the line, because the `/std:c++17` that `-Xcompiler`
forwarded is what `cl.exe` actually sees last.
### The fifth point deserves to stand on its own, because it is the one
nobody reproduced
Points 1–4 were each found by hitting them, in sequence: each is only
reachable once the previous is fixed. The fifth was found by reading the line
above the fourth:
```python
f"/LIBPATH:{tvm_ffi_lib_path}"
```
It is the same unquoted `/LIBPATH:` as (4) and it has never been reported
failing — because `tvm_ffi_lib_path` points inside the virtualenv, where there
is usually no space. **It waits for a machine whose user name contains one**,
and anyone can check that reading without reproducing anything.
That is also the reason for reporting the five together rather than
separately: they are not five unrelated bugs, they are one branch that has
never been run end to end, and the fifth is the evidence that the list is not
necessarily closed.
### There is a local patch, and it is meant to be deleted
We carry these as a versioned patch file against `0.1.13.post3` rather than
editing the installed package, so a clean install rebuilds the same divergence
instead of silently lacking it. It names this issue, and it says to delete the
file when a released version carries the fix. Mentioning it so it is clear
nothing is being forked quietly.
### What was verified, stated narrowly
With (1)–(4) applied, a CUDA kernel built through `load_inline` compiles,
links and loads on this machine, and the engine using it answers normally. That
is **the Windows branch getting as far as generating**, not the Windows branch
being correct — given that each of the four was only reachable after the
previous, a sixth could sit further along the same path.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
