<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, May 26, 2017 at 10:32 AM Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 25, 2017 at 5:20 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>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`?</div></div></div>
</blockquote></div><br></div></div><div dir="ltr"><div class="gmail_extra">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.</div></div></blockquote><div><br></div><div>Would it make sense then to change from using two booleans, one combination of which is invalid, to an enumeration with 3 states?</div><div><br></div><div>```</div><div>enum ArchiveStyle {</div><div>  AS_Thin,</div><div>  AS_Fat,</div><div>  AS_FatWithFullPaths</div><div>}; </div><div>```</div><div><br></div><div>or something like that?  It's not obvious to an outsider what the various options are just by reading the function signature, perhaps this could make it easier to understand.</div></div></div>