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

Chris Bieneman via llvm-dev
Fri, 22 Jan 2016 18:16:04 -0000

> On Jan 22, 2016, at 6:36 AM, Dan Liew <dan at su-root.co.uk> wrote:
>
> 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

I think that mapping Support -> libLLVMSupport is not the complicated part of
what llvm-config does. The complicated part is what the deprecated support for
dependency graph traversal did. Handling the dynamic lib case is just some extra
functionality that would come along for the ride. llvm-config also has the
benefit of working both with installed and non-installed build directories.

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

I disagree. In cross-compilation CMake already generates host tablegen
executables and a target to generate a host llvm-config. Adding the plumbing so
that CMake does what autoconf used to do and installs the host llvm-config as
llvm-config-host shouldn’t be very difficult.

-Chris