[cfe-dev] RFC: Clang driver redesign
devlists at shadowlab.org
Fri Nov 4 08:21:21 CDT 2011
Le 4 nov. 2011 à 13:42, David Chisnall a écrit :
> Hi James,
> It would be worth linking to this somewhere in your draft, as a lot of the issues have already been discussed:
> On 4 Nov 2011, at 11:11, James Molloy wrote:
>> The first draft of this document is attached in HTML form and inline below
>> in ReST form. I've documented the obvious use cases that I can think of, but
>> I am certain to have missed some out. I've also started a strawman proposal
>> solution, with the intention of stimulating discussion by providing
>> something concrete.
> Since we're throwing up use-cases, here are the ones I have where the current driver is not the best:
> Shipping a cross-compile toolchain: Most of these include gcc, binutils, headers and libraries. Including clang with the toolchain wouldn't make sense, because it would be the same clang as the version for the host system, unlike GCC where you need one specifically configured for each target. Ideally, you'd just provide a config file that would tell clang where to find everything and it would just work.
I'm with you on that one. I really dream of something like having a "sdk folder" which contains headers, libraries, binutils (if needed), and a configuration file, and just being able to invoke clang, telling it where the folder is, and having it cross compile my code.
The configuration file should have a predefined name and location inside the sdk folder, so you don't have to tell clang where it is, and it should contain default target triple, path relative to the SDK root of headers, libraries, tools, and any other information clang need, so you just have to drop the sdk folder wherever you want, and invoke clang with something like this:
clang --sdk=<path to my sdk>
More information about the cfe-dev