search

compiler-research / CppInterOp

A Clang-based C++ Interoperability Library
Other
47 stars 21 forks source link

MakeResourcesPath shouldn't be using a hardcoded absolute path on windows #194

Open fsfod opened 8 months ago

fsfod commented 8 months ago

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: https://github.com/compiler-research/CppInterOp/blob/e61e7ca3a7daaa9031785baf0f8cf974e02d21d4/lib/Interpreter/CppInterOp.cpp#L2438-L2444 but in CMake its unconditionally set here: https://github.com/compiler-research/CppInterOp/blob/e61e7ca3a7daaa9031785baf0f8cf974e02d21d4/lib/Interpreter/CMakeLists.txt#L99-L101

vgvassilev commented 8 months ago

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?

fsfod commented 8 months ago

It would ..\lib from the executable directory i think, which is what the other side of the #ifdef gets close to doing.

vgvassilev commented 8 months ago

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...