compnerd added a comment.
@labath - but that is the reality of this: there *are* two classes of
dependencies. I think that if we try to split up all the modules into linked
libraries and header-only libraries, we are going to make an even bigger mess
than what we have.
Repository:
rLLDB LL
labath added a comment.
Or another thing: if one sees a header from module X being included in file Y,
then it's reasonable to assume it's fair game to include another file from the
same module X is fair game. But this creates a two classes of header files:
files in X, which don't have a link d
compnerd added a comment.
@labath - I don't have a problem with the dependency - we can do a
`add_dependency` for the plugin. My issue is that this should not be linked
against. This mess of dependencies makes it difficult to track down the bloat
in `lldb-server`. Currently, `lldb-server` we
compnerd updated this revision to Diff 197793.
compnerd added a comment.
convert link to a proper dependency
Repository:
rLLDB LLDB
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D61361/new/
https://reviews.llvm.org/D61361
Files:
source/Plugins/Instruction/ARM/CMakeLists.txt
Index
labath added a comment.
My point is that we shouldn't need to differentiate between "link" dependencies
and "other" dependencies, as it's not a well-defined boundary. It's easy to
turn one into the other by moving things in or out of line. Hence my suggestion
- move the required things into a d
labath added a comment.
I don't think this is a good way to solve this problem. The llvm's definition
of dependencies http://llvm.org/docs/CodingStandards.html#library-layering
explicitly that it is not the same as "the thing that's needed to make linkers
happy" (emphasis mine):
One library
compnerd created this revision.
compnerd added reviewers: davide, aprantl, clayborg.
Herald added subscribers: kristof.beyls, javed.absar, mgorny.
Herald added a project: LLDB.
lldbPluginInstructionARM does not depend on lldbProcessUtility at link
time. The dependency is for defines and helper fu
