[PATCH] LibDriver, llvm-lib: introduce.

[Rafael Espíndola]

On 6 June 2015 at 19:07, Peter Collingbourne <peter at pcc.me.uk> wrote:
> On Sat, Jun 06, 2015 at 07:01:21PM -0400, Rafael Espíndola wrote:
>> On 6 June 2015 at 18:57, Peter Collingbourne <peter at pcc.me.uk> wrote:
>> > On Sat, Jun 06, 2015 at 01:25:52PM -0400, Rafael Espíndola wrote:
>> >> The lib format is really similar to the .a format.
>> >>
>> >> I guess the only question I have about this direction is how would it
>> >> compare with having lld fork+exec llvm-lib.exe and implementing
>> >> llvm-lib.exe in the same binary as llvm-ar.exe (similar to how we do
>> >> for llvm-ranlib.exe).
>> >
>> > Either way seems reasonable to me, but I see a few minor advantages of the
>> > approach I took:
>> >
>> > 1) The lld tool is more self-contained, so it could be shipped on its own
>> >    if a target build system does not need lib.exe.
>> > 2) We save the cost of a fork+exec which could be expensive on Windows.
>> > 3) Setting up the fork+exec is more code than a function call.
>> >
>> > One disadvantage is that there would be no way to swap out the llvm-lib.exe
>> > tool with another tool that supports something that our tool currently
>> > doesn't support (e.g. generating import libraries), but arguably the right
>> > thing to do there would be to build that functionality into our own tool.
>>
>> OK, I think I am sold on the library idea, but can llvm-lib.exe still
>> be implemented as just another name of llvm-ar?
>
> Sounds reasonable, I'll do that.

Cool, Rui, are you also OK with the general direction?

Cheers,
Rafael