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

[David Blaikie via llvm-commits]

On Fri, Jun 2, 2017 at 11:44 AM Zachary Turner <zturner at google.com> wrote:

> 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.
>

What's the debt, exactly, though? Discoverability for developers? I'm not
sure if people will be more likely to know that DWARF.h is there than in
Support, but maybe.


> 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.
>

Having super granular libraries I think may come at some cost - more places
to go looking for/wonder if that's where the thing you want is residing.


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

I'm not sure I follow what you mean by that (how the second sentence
describes a practical benefit implied by the first)


> Any tool that did not depend on one of those two libraries should now
> build faster and be smaller in binary size.
>

Why would it be smaller in binary size? Unused code wouldn't be linked in.


> 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).
>

*nod* Sure enough, though I'd be surprised if that really mattered to any
build - modifying DWARF.h will cause you to rebuild something else that'll
take a lot longer than FileCheck with or without the change.

As you say, though, unlikely to be harmful - but confusing to me.

Carry on :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170602/9308b805/attachment.html>