[PATCH] LibDriver, llvm-lib: introduce.

[Rui Ueyama]

On Sat, Jun 6, 2015 at 6:53 PM, Rafael Espíndola <rafael.espindola at gmail.com
> wrote:

> 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?
>

Yes, I'm fine with this. Thank you for doing this, Peter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150606/959caa59/attachment.html>