mz2
commented
2 years ago A few more things to note now that I am reading through it myself:
- I'm not sure the idea of adding to the set of paths as done here is actually the best one. Perhaps instead when this env var is populated, it should override (be the only path considered)? This is so that you can indeed choose the exact version amongst many possibly available (for example on my M1 machine I hit this situation https://github.com/thlorenz/rid/issues/31#issuecomment-929189081 where the path is in principle valid, but that build of the library doesn't have the slice for the needed architecture).
- In the same vein, the
:separated list as a format is probably nonsense, and the expectation should be just a single path.
thlorenz
Adds handling for a
LIBCLANG_PATHenvironment variable to allow passing in custom paths for the Clang dynamic library. I found myself again adding to the set of fixed paths inhost_props.rsas I upgraded my copy of LLVM between major versions on macOS, and on Ubuntu 21.10 so figured I'd instead tackle this in some more generalisable way.Also suggesting this since keeping with the convention of adding fixed paths is not going to be a very good solution on at least macOS, since people often keep multiple Xcodes around seasonally (stable release, plus beta version for the upcoming SDK / OS release, etc) and the exact LLVM you're going to want to depend on can be a user specific weird path for example in those cases (beside my unusual "homebrew under home directory" setup).
I'm posting this really to propose the idea (also as a means of fixing #31), happy to try clean up the implementation further if the idea seems sane.
(Also, apologies, I seem to have accidentally opened this branch on the upstream repo at first -- I imagine I am not intended to have direct write access to the upstream repo?)