- User Since
- Jun 25 2018, 2:18 PM (126 w, 6 d)
Fri, Nov 20
Wed, Nov 18
Mon, Nov 16
Note the test case shown here passes on master, so we can drop this
Mon, Nov 9
Mon, Nov 2
Oct 30 2020
Oct 29 2020
Thanks! I actually just requested access so we'll see!
Thanks! I don't have commit access do you mind landing this for me?
Thanks! I don't have merge access do you mind helping me land this?
Oct 28 2020
Thanks all! Can someone land this for me again?
Oct 23 2020
Oct 21 2020
Make function static
Oct 20 2020
Remove unused enum
Thanks for the review!
Address review comments
Oct 19 2020
I believe my author info was correct, but I've updated it using the command mentioned in the doc. Thanks!
Thanks! I don't have merge access can you help me land this?
Add comment about recalculation
Oct 16 2020
Rename to -prepend_rpath
Sep 22 2020
Should we wait for that one to land and then pick this one up? Otherwise any thoughts on the outstanding discussion?
Sep 21 2020
With D87928 do you think we would want this flag as well? The only difference I can think of (besides general UX) is if you need to remap paths outside of your source root, I believe having a *-prefix-map style flag makes that a bit more clear (or potentially possible at all). Ideally there wouldn't be issues around that but in the past in the Apple toolchain the Xcode path was embedded in debug info (as an example), so to get a reproducible build we had to pass -fdebug-prefix-map=/path/to/Xcode.app=SOMETHING. Which -fdebug-compilation-dir . couldn't solve. I'm wondering if we should add both flags for this flexibility, or if we should assume this should not happen?
Sep 15 2020
Sep 12 2020
Sep 9 2020
Sep 8 2020
Rename from fcoverage-prefix-map to fprofile-prefix-map
Aug 18 2020
Yes I do, sorry I've been a bit busy, I will try to get to this later this week
Jul 16 2020
Is there a build step executing llvm-nm that chokes on this? Can you say more about the use case?
Jul 14 2020
Jul 6 2020
I originally implemented this behavior behind -fdebug-prefix-map but there was some pushback, more context: https://lists.llvm.org/pipermail/cfe-dev/2020-June/065668.html
Jul 4 2020
Fix tests on Windows
Jul 3 2020
Open question: I don't know how all the toolchains fit together, but I noticed that only Clang.cpp handles -fmacro-prefix-map, but Clang.cpp, FreeBSD.cpp, and Gnu.cpp all handle -fdebug-prefix-map. I wasn't sure which pattern I should follow here, so right now this only adds the handling to Clang.cpp, please let me know if that's not appropriate in this case!
Jul 1 2020
Jun 11 2020
No problem, thanks!
Jun 8 2020
@fhahn can you help land this? I don't have access. The failure does appear to be related but it seems like just applying this patch is failing, which I don't understand
Jun 6 2020
Jun 4 2020
FYI I actually removed that piece this morning since I felt like since this now supports -path-equivalence=.,foo which is the "expected" behavior from lldb, that was "good enough". lmk if you want me to add it back!
Update relative paths to include the leading ./
Jun 3 2020
Jun 2 2020
Fix test on windows
May 28 2020
The new test failure appears unrelated to my changes
Thanks I moved them to the bottom and I believe I fixed them on windows!
May 27 2020
I've submitted a related change to accept relative paths for -fuse-ld https://reviews.llvm.org/D80660
Jan 22 2020
Can someone land this for me? I don't have permissions to do that AFAIK
Jan 21 2020
Nov 4 2018
No worries, thanks!
Jul 31 2018
Jul 26 2018
No problem! Yes please! :)
- Hoist LLDB.framework headers copy out of condition
- Make headers a post build command
Jul 25 2018
It seems like if this was a common occurrence, it would've been fixed earlier, so I'm wondering if there's a difference in the way I'm building lldb that causes this. Using cmake: