<div dir="ltr">On Mon, Oct 7, 2013 at 9:32 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 10/7/2013 11:18 PM, Rui Ueyama wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My point is the way to abstract linker input as InputGraph and InputElement itself can be simplified.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Isnt the current model simplistic ?<br>
</blockquote>
Honestly, no, I feel that it's over engineerded a bit and designed to be too generic. It may have been unavoidable with the previous design but we may be able to simplify it with nextFile() infrastructure.<br>
</blockquote></div>
nextFile is intended as a way to model only the resolver. The command line has to be still represented in terms of a Input Graph(ELF linker has different variations and the input graph design still doesnot achieve completeness!).<br>

</blockquote><div><br></div><div>The thing I'd like to see addressed is that we have too many classes to represent input files and their relationships. They are abstract enough to represent any possible linker inputs, especially because of ControlNode which can become any directive, I think we don't really need and want that power. It feels that the right amount of abstraction is less than that.</div>

</div></div></div>