<div dir="ltr">I don't really think an external Python script is a particularly useful thing here. Again, the problem I want to see solved is this:<div>- Debian supports a bunch of architectures.</div><div>- The default compiler is GCC right now, and builds a native GCC on each architecture, with certain ABI/ISA defaults hardcoded. There's also a bunch of work towards supporting the full set of cross-building gccs for building every arch from every other arch. These of course will all use the same defaults for the targets no matter what the host arch.</div><div>- It also ships a clang. The clang *doesn't* have the defaults encoded anywhere.</div><div><br>How to fix that? Two slightly different pieces:</div><div>1) How to encode the default options for a trivial default-target compile? "clang test.c" should Just Work, no extra options needed)<br></div><div>2) How to encode the default options for cross compiles to other architectures? CC="$DEB_HOST_GNU_TYPE-clang" or alternatively CC="clang -target $DEB_HOST_GNU_TYPE" should work.</div><div><br></div><div>Of course, substitute any other distro for "Debian" in the above, and they'll have their own, different, defaults. (Of course, for C Bergström's original problem, rtlib and stdlib).</div><div><br></div><div>There's no auto-detectionish stuff here; it's all explicitly defined by the distribution up front. I also don't see any reason so far that this must be any more complex than adding implicit extra command-line arguments.</div><div><br></div><div>So, why not create an external Driver-Driver? E.g. move "clang" aside to "clang.real", add a python/shell script named "clang" that adds extra args as desired? Well, of course you *could* do that, but I think that's both a cop-out *and* is actually harder to properly implement. Take for example, an x86-64 host, running a clang that defaults to targetting x86-64. If you run "clang -m32 foo.c", it must use the proper defaults for i386, not x86-64. That is: I think the defaults need to be added after calling computeTargetTriple() to get the "real" triple.</div><div><div><br></div><div>For compatibility with existing infrastructure, I don't think requiring new (non-triple) names for targets is really feasible. Debian has defined their list of triples on their distribution and their meaning (<a href="https://wiki.debian.org/Multiarch/Tuples">https://wiki.debian.org/Multiarch/Tuples</a>), and those names are what people expect to target. I believe clang's solution to this problem ought to work within those definitions, not require new ones.</div><br></div><div>I could see having a two-level configuration, though. That is, allow named configurations, separate from the "target" (triple). That doesn't enable anything new, because you could do that with multiple config files anyways. But it might be a convenience, to allow putting a bunch of different systems into a single configuration file.<br></div><div><br></div><div>E.g., a config file could look like this:</div><div><br></div><div><div>{</div><div> "default_config": "Debian",</div><div> "default_target": "mipsel-linux-gnu",</div><div> "config": {</div><div> "config_name": "Debian",</div><div> "triple_config": {</div><div> "triple_match": "mips-*-*-*",</div><div> "add_args": ["-march=mips2"]</div><div> },</div><div> "triple_config": {</div><div> "triple_match": "mipsel-*-*-*",</div><div> "add_args": ["-march=mips2"]</div><div> }</div><div> }</div><div> "config": {</div><div> "config_name": "MyNonGNULinuxDistro",</div><div> "add_args": ["-rtlib=compiler-rt", "-stdlib=libc++"],</div><div> "triple_config": {</div><div> "triple_match": "mips-*-*-*",</div><div> "add_args": ["-march=mips4"]</div><div> }</div><div> "triple_config": {</div><div> "triple_match": "mipsel-*-*-*",</div><div> "add_args": ["-march=mips32r2"]</div><div> }</div><div> }</div><div>}</div></div><div><br></div><div>And then:</div><div># Builds for target mipsel-linux-gnu, with args "-march=mips2" implicitly added from the Debian config.<br></div><div>clang test.c</div><div><br></div><div># Builds for target mips-linux-gnu, with args "-rtlib=compiler-rt -stdlib=libc++ -march=mips4" implicitly added from the MyNonGNULinuxDistro config.<br></div><div>clang --config-name=MyNonGNULinuxDistro -EB test.c</div><div><br></div><div># Don't use any configuration-based customizations</div><div>clang --config-name=none test.c</div><div><br></div><div>I really think something simple like the above would be basically trivial to implement within clang, and solve the problems people need to have solved in this area. And there's no need to block on the massive triple/tuple refactoring, or anything like that.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 14, 2015 at 4:57 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.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 14 October 2015 at 21:17, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br>
> Thanks for the subject line pointer, this is the thread I meant. I need to<br>
> review the proposal a bit more, but on the surface it seems not-terrible :)<br>
<br>
</span>Precisely. That's why I want it to be an external Python script for<br>
now, so we can grow with it, and maybe throw it away if we were<br>
completely wrong.<br>
<br>
We should only change the driver if the Python script ends up being<br>
most excellent.<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div><br></div>