[LLVMdev] Can we establish layering for the LLD libraries? Current state is a bit of a mess...

[Greg Fitzgerald]

Hi Chandler,

> Let's start with the purely link-level dependencies encoded in the CMake build

I've been playing around a bit with this.  Looks like we can solve
most of the issues by dissolving lldReaderWriter.
Reader.cpp/Writer.cpp go into lldCore and the rest go into lldDriver.
I don't know if that makes conceptual sense, but it's what breaks the
cyclic dependencies.

-Greg

On Mon, Jan 19, 2015 at 6:33 PM, Chandler Carruth <chandlerc at google.com> wrote:
> I wanted to go through and map out the layering of LLD's libraries today and
> found that it's essentially impossible. I think some serious cleanup is
> needed here.
>
> Let's start with the purely link-level dependencies encoded in the CMake
> build:
>
> Curently the Core library depends on the ReaderWriter/Native library, which
> links against the ReaderWriter library, which links against the Core
> library. This clearly cannot work. The same cycle exists with Core -> YAML
> -> ReaderWrite -> Core.
>
>
> The situation seems a bit worse for includes. If you start from
> LinkingContext.h I think this becomes quite clear. This is ostensibly part
> of the Core library, but it has methods that produce types from the
> ReaderWriter library. Combined with the fact that ReaderWriter depends on
> Core (not the other way around) and ReaderWriter/ELF subclasses
> LinkingContext, I can't make heads or tails of what was intended here.
>
>
> My vague guess is that Core should actually be two libraries. One that
> doesn't depend on anything (other than Config) and provides the very "core"
> types for LLD. And another, perhaps called "Linker" which is a much
> higher-level library and provides useful APIs for actually doing linking,
> depends on ReaderWriter and provides methods that manipulate it. I could
> even see needing to spilt the target libraries in a similar manner.
>
>
> But I don't know LLD's design well, I'm just trying to stitch the build
> system back together in a reasonable way, so maybe I've missed things
> completely. So help me out. I'd like to understand a reasonable DAG in which
> to construct libraries for LLD. Having this should allow proper layering,
> layering checks, and eventually building with C++ modules. All of which seem
> essentially impossible today.
>
> -Chandler
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>