labath wrote: Okay. The last comment makes sense to me. Thank you for getting to the bottom of this. I fully agree this should be resolved in lldb as lldb-server has no good reason to depend on this code in the first place.
So as far as I am concerned (I can't speak about others), I think something like this could work under two conditions: - we make some effort to me this look like other code. What I mainly mean is, each of our cpp files has a header which declares the things defined in that cpp file. I think we should create a matching .h file for the code you're moving here. I guess that means changing MethodName from a nested class to a top-level entity. - you don't get to cry foul if some future change causes lldb-server to become large again. Parts of lldb (including the code you're just moving) still depend on clang, so it's possible that a perfectly reasonable change will cause these things to get pulled in again. I don't think it's likely to happen, as this code is pretty stable and isolated, but still... It also doesn't mean you can't complain if someone introduces a new plugin dependency (in fact, I encourage you to do that). However, I don't think it's reasonable to hold up changes to code which is within its right to depend on clang, just because it makes lldb-server larger due to these unresolved dependencies. *That said*, I would much very much prefer to resolve this in a proper way, by removing the (direct) dependency on the C++ language plugin. It sounds like https://github.com/swiftlang/llvm-project/pull/3240 is not far from working. As far as I am concerned (I again don't speak for others), the plugin ordering thing could be handled by making sure the plugins are registered in the right order (in cmake). https://github.com/llvm/llvm-project/pull/132274 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
