[PATCH] D33843: Create a new library called ObjectLayout, and move headers from Support to there.

[Zachary Turner via llvm-commits]

On Fri, Jun 2, 2017 at 11:23 AM David Blaikie <dblaikie at gmail.com> wrote:

> I'm still missing some of the motivation as to 'why', here.
>
> If there are significant uses of a library that don't use most of it -
> yeah, i think there's merit in separating things out (eg: if lld, lldb,
> etc, use, say, the DWARF constants but not the rest of Support/ADT - yeah,
> it'd be nice if they didn't have to rebuild whenever SmallString changed,
> for example). (though even then, Ninja's pretty efficient about only
> rebuilding what it has to, so I'm not sure that even the library
> granularity changes much about the build performance here - header
> dependency could be something to care about there, for sure (fewer long
> chains of dependent headers, breaking a header into two if there's
> functionality that is used broadly next to functionality that has a narrow
> use, etc).
>
> What's the goal/metric/benefit?
>

First, there is the intangible benefit.  DWARF.h and WASM.h simply do not
make logical sense in Support.   This might seem like a minor point, but I
put this into the "technical debt" category.  By not enforcing strict
guidelines of what goes into Support, we build up technical debt over time
as a bunch of unrelated stuff piles into it.  We can do better than this.

Second, libraries as an abstraction are virtually free, and the point of
them is to group related things together.  One could probably even argue
they are better than free, as they have less than or equal to zero cost
since at worst they do nothing, and at best they speed up your build and
reduce your binary size.

Third, there is the practical benefit.  The only LLVMBuild.txt files
modified here are lib/IR and lib/Object.

Any tool that did not depend on one of those two libraries should now build
faster and be smaller in binary size.  I don't have a list of which tools
satisfy that condition, however, but it's definitely non-empty (FileCheck,
for example, is an obvious candidate).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170602/5ccb8f92/attachment.html>