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

[Zachary Turner via llvm-commits]

As an aside, now I have a logical place to put lots of stuff related to
CodeView record formats.  Not having that is part of why I had to add a
dependency from ObjectYAML to DebugInfoCodeView, but once we have that it's
conceivable I could get enough of the format definitions moved over to
ObjectFormat or BinaryFormat that we won't need this dependency anymore.
But it's spread across 5+ files because there's so much of it, and it would
just pollute Support for no good reason if I were to put it there.

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

> 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/e9dc4d50/attachment.html>