[llvm-dev] Building SVN head with CMake - shared libraries?

[Dan Liew via llvm-dev]

On 20 January 2016 at 21:11, Chris Bieneman <beanz at apple.com> wrote:
> I didn’t realize we had deprecated the dependency walking code, which actually makes me a little sad, but I’ve been thinking about this, and I think we’re making this all too hard on ourselves.
>
> A lot of the work we’re doing here is actually just duplicating functionality already in llvm-config. Doing a normal in-tree build we can’t use llvm-config because we need the information at configuration time before llvm-config is built. For this use case, where you’ve already built LLVM and are essentially building LLDB as an out-of-tree project, we could use llvm-config because it should already be there.
>
> Doing that would mean we don’t have to duplicate logic between the llvm-config tool and our CMake builds, and not duplicating things is generally good.

I agree that duplicating functionality is usually not a good thing but
I see two reasons why we **should not** go down the route of invoking
the ``llvm-config`` executable for external projects

* As you said this some of this functionality basically needs be in
LLVM for its configure step. So we get the hard bit (mapping
components to module library names e.g. support -> libLLVMSupport.a)
for free. Supporting the dynamic lib case adds a small complication
but it's certainly possible

* Requiring clients to invoke (indirectly via whatever CMake interface
we provide) the ``llvm-config`` executable screws things up for those
doing cross compilation because ``llvm-config`` might not be compiled
to target the host machine.