[PATCH] request for approval to commit: llvm-c: Make target initializer functions external functions in lib.

Filip Pizlo fpizlo at apple.com
Mon Sep 30 12:31:04 PDT 2013


On Sep 30, 2013, at 12:06 PM, Rafael EspĂ­ndola <rafael.espindola at gmail.com> wrote:

>> 2) Compile and link a program that uses LLVM, but have it pull in only the
>> static libs for the targets that the program wishes to use.
>> 
>> With this proposed patch, (2) won't work anymore.  You'll get a link error
>> since Target.cpp now requires all of the targets with which LLVM was
>> configured to also be linked by the client.
> 
> Good point. What about putting these functions in a AllTargets.cpp?
> That way a program that wants just some targets can call just the
> initialization functions for those targets and not pull in
> AllTargets.o.

Would you then also have a libLLVMAllTargets.a?

I mean, it seems like it would work, but I just want to make sure I'm on the same page as you about why this is better than what LLVM does today.  For programs that already build against all of LLVM's targets, presumably they do it by static linkage - in which case what LLVM trunk does right now is fine:  llvm-config will tell you to link all of the .a's, and the header file will have that static inline function that initializes all of the targets.  It works for those use cases, and it also allows cherrypicking: a client can ignore part of the --libs list from llvm-config and then initialize targets directly.

So, having AllTargets.cpp would mainly be beneficial for those who build LLVM as a single shared library, rather than as static libraries.  Is that what we're going for here?

-Filip

> 
> Cheers,
> Rafael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130930/beb83b78/attachment.html>


More information about the llvm-commits mailing list