zturner added a reviewer: rsmith. zturner added a comment. But wouldn't doing that manual merge once then make things easier for the future? For example, if you merge back to a branch that doesn't have `ClangUtil.cpp`, and then you just add `ClangUtil.cpp` to that branch, the problem is solved for the future. So while it's an annoying manual merge, it only has to happen once. Incidentally, splitting up code like this makes merges easier over the long run, just like the example you gave with `DWARFASTParserClang` where now language specific stuff is in its own file.
idk, I just don't feel very good about starting from the premise that code re-organizations are discouraged because of X, where X is, well pretty much anything. It's impossible for everyone to know about all the issues that all the downstream customers have to deal with, and in principle I feel like changes such as this should even be able to go through without review because the technical merits of having a healthy code organization are well understood, and while discouraging code re-organization might make one particular customer's life easier, I think it weighs on the larger project and indirectly every other downstream customer as a result. I'm curious now what clang does in this regard, so +rsmith in case he has some insight into what happens in clang when someone wants to re-organize some code and how other downstream customers (for example, swift) deal with this. Just to be clear, I'm genuinely sympathetic to the issues other people have to face with regards to their downstream build issues, so if there's any way for me to make this less painful I will go out of my way and spend extra time to make it so. But I think we should only be discussing the technical merits of the design and whether the code organization. http://reviews.llvm.org/D18530 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
