[PATCH] D33575: [llvm-ar] Make llvm-lib behave more like the MSVC archiver

[Reid Kleckner via llvm-commits]

On Thu, May 25, 2017 at 5:20 PM, Zachary Turner <zturner at google.com> wrote:

> I guess it's possible I'm just missing something, but what I don't
> understand is why `Thin` can't just be the only determining factor of
> whether we write full paths.  Why the second variable?  AFAICT nowhere in
> this patch is `false` ever explicitly passed, it only takes on a `false`
> value implicitly when `Thin` is also false.  So just delete the variable,
> and only use the value of `Thin`?
>

Microsoft tools won't understand thin archives. Thin archives leave the
object files on disk instead of copying them into the archive. The whole
point of this patch is to make llvm-lib.exe behave more like lib.exe, so it
would defeat the purpose if we went our own way here.

On Thu, May 25, 2017 at 5:55 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> > The names we invent for import files don't have path separators in them,
> so
> > there should be no behavior change either way here. By passing true, we
> > don't needlessly run sys::path::filename on them. Are you suggesting that
> > maybe it will cause us to not use the short strtab format? I guess I'll
> > change it back. Most DLL names are < 16 characters.
>
> How about passing the final name to useStringTable? That way it can just
> check if there is '/' in it or if it is too large.
>

Sure. So, if the relative path from a thin archive to the object file is <
16 chars and has no slashes, is it OK to store it in the archive member
header?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170526/1993c042/attachment.html>