You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The build path of the binary that CppInterOp.cpp is compiled in to on windows is unlikely to be the same it run with, but MakeResourcesPath always uses LLVM_BINARY_DIR because it always set by llvm cmake a far as a i can tell.
The macro is conditionally used in the code here:
Yes, that is the intent for now. This logic is needed to be able to pass the correct resource directory path (-resource-dir) to the compiler. Where does are the compiler resource headers put on windows if not relative to the LLVM_BINARY_DIR?
It would ..\lib from the executable directory i think, which is what the other side of the #ifdef gets close to doing.
We don't have a reasonable way out I fear here. The problem with the other part of the ifdef is that it works well for the binary clang. The installation location of the clang binary is pretty well known and the relative computation of the paths works well. The problem for CppInterOp is that it is a library and can be installed on many more different locations. That's why we have relied on the LLVM_BINARY_DIR which seems to be somewhat more stable. Apparently that needs more work on Windows I guess...
The build path of the binary that CppInterOp.cpp is compiled in to on windows is unlikely to be the same it run with, but MakeResourcesPath always uses LLVM_BINARY_DIR because it always set by llvm cmake a far as a i can tell.
The macro is conditionally used in the code here:
CppInterOp/lib/Interpreter/CppInterOp.cpp
Lines 2438 to 2444 in e61e7ca
but in CMake its unconditionally set here:
CppInterOp/lib/Interpreter/CMakeLists.txt
Lines 99 to 101 in e61e7ca
The text was updated successfully, but these errors were encountered: