<p dir="ltr">On Oct 15, 2015 4:21 AM, "Renato Golin via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> On 15 October 2015 at 12:05, Daniel Sanders <<a href="mailto:Daniel.Sanders@imgtec.com">Daniel.Sanders@imgtec.com</a>> wrote:<br>
> > I can see the overlap between this and that. If I understand correctly, it's trying to take a JIT's ability to know exactly what the target hardware is and use that to drive normal compilation. For my case, I want the target to be what the distribution wants it to be (which is often a subset of the actual hardware) but both cases require the same ability to modify the target based on a configuration.<br>
><br>
> It's actually both. And safe by being an external prototype first.<br>
><br>
> The first stage is to understand the host/target machines and create a<br>
> description (CFLAGS). The second stage is to turn that into a text<br>
> database (JSON) so that people can add their own by hand *in addition*<br>
> to automatically detect it.<br>
><br>
> So, in your case, if Clang would understand such database, you could<br>
> create fedora-mips-linux-gnu and debian-mips-linux-gnu configuration<br>
> *names* (not triples) and use that to set all the flags that make<br>
> sense for each.</p>
<p dir="ltr">I'm not sure what distinction you're trying to draw here, given that "configuration names" is the proper term for the thing we inaccurately call a triple (see <a href="https://www.sourceware.org/autobook/autobook/autobook_17.html">https://www.sourceware.org/autobook/autobook/autobook_17.html</a>).</p>
<p dir="ltr">> I believe we have to try very hard to keep compatibility with CFLAGS<br>
> even after Clang understands the database because of other compilers.<br>
> Once we have meaning inside the database that cannot be represented by<br>
> flags, people will be locked in, and I want to avoid that at all<br>
> costs. Even if the flags are ugly, they have to be standard. The<br>
> ugliness will be hidden by the database anyway.<br>
><br>
> So, a proposed format would be something like:<br>
><br>
> [<br>
>   { "name": "fedora-mips-linux-gnu",<br>
>     "cflags": "-march=mips -mcpu=whatever --blah",<br>
>     "arch": "arch",<br>
>     "cpu": "cpu",<br>
>     "endian": "blah"<br>
>   },<br>
> ]<br>
><br>
> So, we always keep the cflags / cxxflags, even when all the other<br>
> parameters made it redundant. The tool also has to be able to produce<br>
> a CFLAGS from the other parameters and update the database. This way,<br>
> it would be ludicrously simple to write a script for GCC to use this<br>
> without asking them to implement anything on their front-end. We can<br>
> also easily add more cflags just for gcc, icc, pcc, armcc, etc.<br>
><br>
> cheers,<br>
> --renato<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</p>