[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:53 AM David Blaikie <dblaikie at gmail.com> wrote:

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

 I guess it's the same argument you would make to justify any library
separation -- Group related things together.  Libraries are more than just
a build system implementation detail.

If the only valid justification for creating a library were to improve some
measurable metric in build time then we wouldn't have things like
ObjectYAML, we could just put DWARF Yaml code inside of DebugInfo/DWARF,
and COFF Yaml code inside lib/Object, etc.  After all, the linker will just
strip all the stuff that isn't used, so any tool that doesn't care about
converting between binary and yaml formats would be unaffected.  But we put
them together because it "makes sense"™ even though there's only a couple
of files.

Perhaps the debt isn't obvious when llvm/Support "only" has 147 files.
What about when it has 247?  A year ago llvm/Support had only 116 files
<https://github.com/llvm-mirror/llvm/tree/caeade42341b7b7a14b4e6bd13aeccd4a1da452a/include/llvm/Support>.
I think the barrier to entry for getting stuff in support should be high
(and I say this as someone who has dumped some stuff into support because
that's what precedent had decided you do when you want to share some code)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170602/9b4115aa/attachment.html>