<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 7, 2014 at 2:22 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/7/2014 4:10 PM, Nick Kledzik wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Shankar,<br>
<br>
Can you give provide a scenario where you want this?  I’m not sure what you want here.<br>
</blockquote>
<br></span>
a) LLVM could be built  just for one target(LLVM_TARGETS_TO_BUILD)<br>
b) With LTO this case might happen more often, where an user would have compiled LLVM just for one architecture and lld would support other architectures that LLVM would not support.<br>
c) Printing all the targets/flavors that the linker currently supports.</blockquote><div><br></div><div>What's the motivation to build a LLD only for some specific target? Size?</div><div><br></div><div>LLD is not a large executable. When compiled with Release, it's a few megabyte binary. If you kill architectures that you don't need, you won't save that much.</div><div><br></div><div>On the other hand, making something configurable always comes with cost. It's not hard to imagine that we would get a bug reports that "feature X didn't work if we build LLD only for target Y."</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Oct 7, 2014, at 2:03 PM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I think lld needs to have an infrastructure as part of the build process to build specific flavors and specific targets.<br>
</blockquote>
This sounds like you want config-time choices (e.g. build a linker to only support ELF/x86 such as for a JIT).<br>
</blockquote></span>
Yes.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For this I was thinking that the Registry expand to consider flavors and targets that are part of the build process.<br>
<br>
So each flavor/target would register and the Driver would walk through the list of handlers to check if there is a handler defined for that flavor/target.<br>
</blockquote>
This sounds like you want everything decided at runtime (e.g. all flavors registers all readers).<br>
</blockquote></span>
Yes, right.<div class="HOEnZb"><div class="h5"><br>
<br>
Shankar Easwaran<br>
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
<br>
</div><div class="h5"><br></div></div></blockquote></div></div></div>