- User Since
- Feb 11 2015, 3:26 PM (268 w, 6 d)
Not sure who to add -- I'm sending an email to the list with a link to this review.
Ok, let's go step by step to make sure we don't talk past each other. Here's some facts (feel free to correct me if you see a mistake):
Could you please chime in on http://lists.llvm.org/pipermail/libcxx-dev/2020-April/000793.html? I'd like to better understand why we even need to support a standalone build -- I thought we were not supporting those anymore since the monorepo.
I like this.
My preference would be to set nothing at all. Just let users say -DCMAKE_POSITION_INDEPENDENT_CODE=ON/OFF in their own caches. Why doesn't that work?
Adding folks who might be interested. I'm especially interested to know if anyone's workflow differs from what I'm documenting in my changes, and if so, how does it differ.
Also, just to explain how I'm currently running the tests with this patch applied:
This review is a WIP for solving remote execution of libc++ tests with lit better than we currently do. See the review summary for the initial discussion.
Mon, Apr 6
As discussed offline, done as 267273563dd974abe1d7cda4513fef884cf0eb3e.
After offline discussion with @broadwaylamb, we went ahead with b00a874b7c7371 instead. The main difference is that b00a874b7c7371 makes sure to close the NamedTemporaryFile before it tries to scp it, which is more in-line with the Python documentation:
Thanks for looking into this!
This is a no-op change unless one opts into the new format. Just to follow protocol, I'll still wait for a libunwind owner to approve.
Sun, Apr 5
@modocache We have a libcxx review group that gets added as a blocking reviewer on libcxx patches automatically, that's for a reason. Please don't commit without an approval from the group anymore.
Sat, Apr 4
Fri, Apr 3
Like I mentioned in the commit message, this simply fixes the place where the recursiveExpansionLimit is set. Regardless of that, I still plan to explore addressing concerns raised in https://reviews.llvm.org/D76178, which is somewhat orthogonal.
Thu, Apr 2
This is mostly a heads-up review. I welcome comments and improvement suggestions. This patch is a no-op unless one opts into the new format, and in particular this doesn't change the interaction between CMake and config.py at all. Because of this, I will not hold off committing this in order to start adopting it more widely right away -- improvements can be made as follow-up patches as I get more feedback from people who try it out.
Just trying to wrap my head around this. Basically, this makes lit.cfg files relocatable, however doesn't everything else need to be relocatable too for anything to work? For example, if you set the rpath on some executable, that needs to be relative too, right?
Got offline approval from Eric to land this, with the intent of doing a post-commit review.
There is a patch for this: https://reviews.llvm.org/D68269
LGTM, but is there some documentation about how to build libc++ standalone? How do you build it? Do we have any bots that exercise this code path?