[PATCH] LibDriver, llvm-lib: introduce.

Peter Collingbourne peter at pcc.me.uk
Sat Jun 6 16:07:13 PDT 2015


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.

Thanks,
-- 
Peter




More information about the llvm-commits mailing list