<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 18, 2014 at 1:38 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">> I meant that I had to use a hack to feed the files to llvm-link (crazy<br>

> escaping monstrosity), not that the use case is a hack.<br>
<br>
</div>Well, it is a hack. That is not how we are implementing lto on trunk.<br></blockquote><div><br></div><div>By "use case" I meant "feeding a directory of files to llvm-link", not the overall script. Feeding a directory of files to llvm-link sounds like a perfectly normal thing to do.</div>
<div><br></div><div>Besides, making the tool easier to use is not a concession that it should be used for production purposes or is supported for production purposes; it's just that: making the tool easier to use. Think about it this way: if llvm-link were originally written with this behavior, would you be dying to rip that functionality out?</div>
<div><br></div><div>Khilan, sorry for all this crossfire on your first patch. I'd like to see another iteration of this patch with the behavior I described:</div><div>"<span style="font-family:arial,sans-serif;font-size:13px">Even better: there is no -dir argument. Positional arguments can be either bitcode files, or directories. If a positional argument happens to be a directory, it is scanned for bitcode files, which are added to the list of inputs. It is not an error to specify a directory that contains no bitcode files."</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">Actually, I'd prefer an incremental step of just detecting directory arguments and adding all files in the directory (a future patch can filter bitcode files if that feature seems useful).</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">-- Sean Silva</span></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class=""><br>
>> llvm-link is just a developer tool. Any use of it for production<br>
>> purposes is an unsupported hack. Which sometimes is the right thing to<br>
>> do, but still a hack and still unsupported.<br>
><br>
><br>
> This is a slippery slope. Developer tools exist because they make<br>
> developers' lives easier. Adding features which make developers' lives<br>
> easier is the right thing to do. We have concrete experience showing that<br>
> this sort of feature fits a real use case for the tool and significantly<br>
> simplifies its use; that's enough reason for me to consider it worthwhile to<br>
> have in-tree (especially since it's a very small amount of logic).<br>
<br>
</div>By developer tool I mean something that is use for testing llvm or in<br>
the day to day tasks of developing llvm. The use case you list is a<br>
way of implementing LTO which is not how we implement it in tree. I<br>
think any support code for it should be out of tree too.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>