<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 8, 2014 at 10:59 AM, Bob Wilson <span dir="ltr"><<a href="mailto:bob.wilson@apple.com" target="_blank">bob.wilson@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Sep 8, 2014, at 10:14 AM, Joerg Sonnenberger <<a href="mailto:joerg@britannica.bec.de">joerg@britannica.bec.de</a>> wrote:<br>
><br>
> On Fri, Sep 05, 2014 at 09:23:34PM -0500, Richard Pennington wrote:<br>
>> Right now it only handles replacing a "-target foo" option<br>
>> with the options defined in the file foo in the resource/config<br>
>> directory, but I think it has potential for doing quite a bit more.<br>
><br>
> Please don't overload the -target option like that, but make it a<br>
> separate option.<br>
<br>
</span>I disagree. One of the problems with clang’s driver now is that we have such a long list of built-in targets. From the user’s point of view, whether the target settings come from a yaml file or from hardcoded logic in the driver should be an implementation detail. It would be great if we could default to specify _all_ targets like this, and then choose which targets to build into the driver based solely on performance. (It will be a while before any mechanism like this can support all the features for some of the more complicated targets, so I’m not proposing that we completely switch to that approach now, but I would like to see us move in that direction.)<br>
<br>
On that note, Richard, do you have any thoughts on how we could support building these yaml specification into the driver? It seems like many of the targets that are currently hardcoded could be handled with this approach, but the compile-time cost of reading a separate yaml file would be unacceptable in some situations.<br></blockquote><div><br></div><div>Right. I was just about to mention this. It has, historically, been a design requirement of the driver that the load time of a separate file is unacceptable. A separate option of reading in a file with config data might be useful in some cases, but I think we should see what the actual use cases are here first :)</div><div><br></div><div>-eric </div></div></div></div>