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

[fsfod]

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

	#ifdef LLVM_BINARY_DIR
	Dir = LLVM_BINARY_DIR;
	#else
	// Dir is bin/ or lib/, depending on where BinaryPath is.
	void *MainAddr = (void *)(intptr_t)GetExecutablePath;
	std::string BinaryPath = GetExecutablePath(/*Argv0=*/nullptr, MainAddr);

but in CMake its unconditionally set here:

CppInterOp/lib/Interpreter/CMakeLists.txt

Lines 99 to 101 in e61e7ca

	set_source_files_properties(CppInterOp.cpp PROPERTIES COMPILE_DEFINITIONS
	"LLVM_BINARY_DIR=\"${LLVM_BINARY_DIR}\";CPPINTEROP_VERSION=\"${_VAR}\""
	)

[vgvassilev]

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]

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

[vgvassilev]

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