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

[Chris Bieneman via llvm-dev]

> 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