llvm dev - Jul 2013 - [LLVMdev] Hi, people, I propose to move Debug and Object File related headers out of Support

On Fri, Jun 28, 2013 at 11:13 AM, Eric Christopher <echristo at
gmail.com>wrote:
> Going to be interesting layering issues if you do the latter. Then you
> have CodeGen depending upon DebugInfo instead of just a header in
> Support.
>
Well, the issue is that LLVM's "libraries" are really not fine
grained due
to our build system/source tree layout, so we end up just glomming together
large pieces of (sometimes vaguely) related functionality into
"libraries",
which are the units of physical dependency. Realistically, Support/ELF.h is
a fine piece of independent functionality that should be independently
reusable, but we don't have effective tools for managing and maintaining
proper physical dependencies to make that happen.

There are actually a bunch of things in Support that I wish could be
independently reused. Like if I want to write up a little program, I really
wish I could do

$ llpm install StringRef ArrayRef raw_ostream MemoryBuffer

and then have it put those relevant modules and their dependencies in a
local `deps/` (or whatever) directory so that I can then just include them
in my build.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130628/d53f198c/attachment.html>

LLVM is a modularized software system, so I hope it's was modularized,
And ELF.h is definitely belongs to Object by classification,
The things that confused me is the ELF.h was placed under Support and
don't know why.
Indeed, I checked that those source codes that include ELF.h also
include files under Object folder,
so that's the reason to move ELF.h from Support to Object.

2013/6/29 Sean Silva <silvas at purdue.edu>:
> On Fri, Jun 28, 2013 at 11:13 AM, Eric Christopher <echristo at
gmail.com>
> wrote:
>>
>> Going to be interesting layering issues if you do the latter. Then you
>> have CodeGen depending upon DebugInfo instead of just a header in
>> Support.
>
>
> Well, the issue is that LLVM's "libraries" are really not
fine grained due
> to our build system/source tree layout, so we end up just glomming together
> large pieces of (sometimes vaguely) related functionality into
"libraries",
> which are the units of physical dependency. Realistically, Support/ELF.h is
> a fine piece of independent functionality that should be independently
> reusable, but we don't have effective tools for managing and
maintaining
> proper physical dependencies to make that happen.
>
> There are actually a bunch of things in Support that I wish could be
> independently reused. Like if I want to write up a little program, I really
> wish I could do
>
> $ llpm install StringRef ArrayRef raw_ostream MemoryBuffer
>
> and then have it put those relevant modules and their dependencies in a
> local `deps/` (or whatever) directory so that I can then just include them
> in my build.
>
> -- Sean Silva


-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

On Jul 4, 2013, at 1:43 AM, 罗勇刚(Yonggang Luo) wrote:
> LLVM is a modularized software system, so I hope it's was modularized,
> And ELF.h is definitely belongs to Object by classification,
> The things that confused me is the ELF.h was placed under Support and
> don't know why.
Because it's also used by the MC layer's direct object emission support.

Chip