- User Since
- Feb 11 2015, 3:26 PM (219 w, 2 h)
I will build a significant codebase with the change and report on the results, since we lack good tests for the removal of /usr/include/c++/v1.
I'll try this out and back out if it breaks something -- I tested locally but we never know.
Mon, Apr 22
Thu, Apr 18
Is there still a reason to maintain the _PSTL_USE_PAR_POLICIES configuration? If not, we should move forward with this patch. I know @rodgert has been bitten by this at least a couple of times.
Rebase onto master
I'm not sure this change is valid because now we're also copying things like attributes, ACL and even the stat of the file. But I wanted to have that discussion in public here for documentation.
Is there anything to fix in this patch? If not, and if that implementation is the correct one given today's backend API, I'd like to check this in so we can do followup cleanup. It'll also help me as I try to see if a more general backend API is possible because I'll have both the TBB and the serial (trivial) examples to work off of.
Wed, Apr 17
I'm relaying approval to @mstorsjo, who seems okay with the change.
Love the cleanup!
I am concerned that we're going to start flagging leaks because we don't destroy those -- do you share the concern? I mean I can also just push and see what our various sanitizers say.
Tue, Apr 16
The fact that we have to add this manually is unfortunate.
Please test your commit access with this.
I think LIBCXX_STATIC_LIBRARIES and LIBCXX_SHARED_LIBRARIES would be better renamed LIBCXX_STATIC_LIBRARY_DEPENDENCIES and LIBCXX_SHARED_LIBRARY_DEPENDENCIES , or something similar. What do you think?
Can you please add context to the diff?
I'd love more FIXMEs to be resolved before we move forward.
Mon, Apr 15
Reverted in r358437 because of unforeseen CI failures. The failures I was expecting are in libc++, not in compiler-rt. I'll investigate locally and re-apply.