JDevlieghere wrote: > FWIW, I completely agree @royitaqi. I'm not saying inter-plugin dependencies > should be a free-for-all (*), but I think that some kinds of dependencies > make sense and I definitely think this is one of them. The debug map format > is intimately tied to the MachO and darwin ecosystems and I think there's > approximately zero chance that it will be implemented elsewhere. Using the > debug map requires MachO files, so why not just admit that? >
To answer your last question: because the plugins (which is really a misnomer), as I understand it, are there to provide abstraction: the caller shouldn't have to know what concrete instance an `ObjectFile` is. The no-plugins-dependency enforces that at compile/link time. I'll be the first to admit that the current approach has shortcomings (like it does here, I totally agree with that). However we should also remember that it exists for a reason and that a lot of time and effort has been spent on detangling the plugins to fix layering issues and reduce binary sizes. The current rule is easy to understand and easy to enforce which makes it appealing and ensures we don't make things worse as we're still working on this. IMHO, the downsides being listed here don't outweigh the benefits, especially since we have a bunch of examples of those "moral dependencies". That said, if there's a way to enforce the DAG described in the asterisk, I'm totally fine with changing the rule to allow inter-plugin dependencies "where it makes sense" (which is still subjective). I made a similar argument in another PR a while ago, but I don't think we can expect reviewers to mentally verify this DAG every time someone tries to introduce a new inter-plugin dependencies. TL;DR: My stance is that if there's a way to enforce the DAG, I'm totally fine with allowing inter-plugin dependencies where they make sense. Barring that I think the current rule, albeit overly strict, is the easiest way to enforce we don't regress inter-plugin dependencies in general. PS: I'm actually glad we're having this discussion. Whatever the outcome, I'd like to [document it on the website](https://lldb.llvm.org/resources/contributing.html) so contributors can know what to expect going forward. This comes up periodically and there's no reason this should be a surprise for existing or new contributors. https://github.com/llvm/llvm-project/pull/139170 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
