[cfe-dev] alternate clang driver
Michael Price - Dev
michael.b.price.dev at gmail.com
Fri Oct 21 17:31:32 PDT 2011
Imagine you are an Engineering Manager at a large corporation,
considering adopting clang. You probably don't want to require your C+
+ developers to know Python, just so they can build their code.
Also, concerning Reed's claim that all solutions will converge to his,
unless he's got a mathematical proof, I'm not convinced. Just because
you were unable to discover a "better" solution, doesn't mean someone
else won't. Or rather, because you failed to accept a simpler
solution, doesn't mean that others wouldn't be okay with that.
Ultimately
Sent from my iPhone
On Oct 21, 2011, at 4:47 PM, cfe-dev-request at cs.uiuc.edu wrote:
> Send cfe-dev mailing list submissions to
> cfe-dev at cs.uiuc.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> or, via email, send a message with subject or body 'help' to
> cfe-dev-request at cs.uiuc.edu
>
> You can reach the person managing the list at
> cfe-dev-owner at cs.uiuc.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cfe-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: alternate clang driver (reed kotler)
> 2. Re: alternate clang driver (James Molloy)
> 3. Re: alternate clang driver (reed kotler)
> 4. Re: alternate clang driver (David Chisnall)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 21 Oct 2011 14:15:58 -0700
> From: reed kotler <rkotler at mips.com>
> Subject: Re: [cfe-dev] alternate clang driver
> To: James Molloy <James.Molloy at arm.com>
> Cc: "cfe-dev at cs.uiuc.edu" <cfe-dev at cs.uiuc.edu>
> Message-ID: <4EA1E10E.4080903 at mips.com>
> Content-Type: text/plain; charset="windows-1252"; format=flowed
>
> I don't buy the C++ is faster that Python argument. It's just a driver
> for a compiler! You could write it in Turing machine primitives and it
> would be super fast on a modern computer. It's not computing the
> strongly connected components of a terabyte sized graph.
>
> I think you will have some kind of scripting component; whether it's
> LUA
> or Python or some hand brewed language format that is read by the
> clang
> driver and then interpreted, that is what you will have when you
> finish
> solving this problem. That is what I meant by all solutions will be
> isomorphic.
>
> Reed
>
> On 10/21/2011 01:56 PM, James Molloy wrote:
>> Hi,
>>
>> Seeing as everyone's putting in their 2cents, here's mine.
>>
>> The problem is that the current Clang driver is not extensible
>> enough, or easily extensible enough. One can argue that a driver
>> doesn't belong in Clang - that's really arguing semantics because
>> the Driver, while living under the clang tree is detached from the
>> rest of Clang and invokes it as subprocesses.
>>
>> My opinion is that the driver should be either:
>>
>> * Pure C++/TableGen with pretty much everything declaratively
>> defined and just some C++ glue. OR
>> * Pure C++, reads some sort of configuration file.
>>
>> The latter allows for distros to more easily adapt Clang without
>> (a) rebuilding it and (b) shoving patches to support their weird
>> directory structure on us.
>>
>> I do *not* think that launching an external scripting language is
>> best for two reasons.
>>
>> Firstly it is slower than pure C++. ("Oh but LuaJIT is fast!", "Oh
>> but Python is fast!", "The driver time doesn't matter!" - it does.
>> Clang has been built around build speed and to clobber all that
>> effort because of laziness in the driver isn't an option IMHO. And
>> interpreters, even LuaJIT, aren't that fast to boot).
>>
>> Secondly because they create an extra dependency which is bad in
>> and of itself IMHO but worse causes real difficulty in the bringup
>> of new, native toolchains. You'd have to somehow cross-compile
>> LuaJIT for your new architecture before you could run a hosted
>> compiler. This is a terrible idea.
>>
>> Reed, to argue that all solutions would be isomorphic to yours is
>> the same as arguing that Python and C are both Turing-complete and
>> so there is no difference in using one over the other.
>>
>> Cheers,
>>
>> James
>> ________________________________________
>> From: cfe-dev-bounces at cs.uiuc.edu [cfe-dev-bounces at cs.uiuc.edu] On
>> Behalf Of Alek Paunov [alex at declera.com]
>> Sent: 21 October 2011 20:46
>> To: Reed Kotler
>> Cc: cfe-dev at cs.uiuc.edu
>> Subject: Re: [cfe-dev] alternate clang driver
>>
>> Hi Reed,
>>
>> I am fully behind your line of thinking, but why not be even one step
>> more "radical" than your first step:
>>
>> XML (or JSON or YAML - some variant of tree with properties as text -
>> never mind, once it is processable) + scripting language which
>> transform
>> the registry to tool invocation parameters.
>>
>> This means just few lines of important scripting code which
>> everyone can
>> modify (in specific cases) and instant understanding of the required
>> data model (because one look at the bundled XML/JSON variants per
>> distribution will be enough for the (even average) developer to
>> realize
>> the actual requirements).
>>
>> I am also long time Linux/Python user, but in my feelings, the best
>> for
>> CLang (because there are other aspects too) at the moment is LuaJIT.
>>
>> Kind Regards,
>> Alek
>>
>> On 21.10.2011 18:51, Reed Kotler wrote:
>>> On 10/21/2011 03:25 AM, David Chisnall wrote:
>>>> On 21 Oct 2011, at 10:30, Jean-Daniel Dupas wrote:
>>>>
>>>>> I'm not sure writing a new driver from scratch is better than
>>>>> trying to externalize the configuration in the current driver.
>>>>>
>>>>> Is there anybody currently working on the universal driver ( http://clang.llvm.org/UniversalDriver.html
>>>>> ) ?
>>>> No one's currently working on it (or, wasn't last week when I
>>>> asked). It's on my to-do list, but keeps getting pushed lower
>>>> down by stuff I actually get paid for...
>>>>
>>>> David
>>>>
>>>> -- Sent from my brain
>>>>
>>> You will see that no matter how you do this, you will ultimately
>>> end up
>>> with an isomorphic solution to what I did.
>>>
>>> You could try and put all the configuration variables in an XML
>>> file.
>>>
>>> That will be like the data structures in my program but harder to
>>> understand when you want to configure things. You can't factor
>>> things
>>> then because it's just a big data file. If you do a lot of
>>> factoring,
>>> you won't be able to understand the file after a while without
>>> building
>>> some tool.
>>>
>>> There are often some tricky things for a given installation, target,
>>> etc. and it's easier to fix this in the driver script than
>>> rebuilding
>>> the front end.
>>>
>>> Dynamic scripting is more natural for handling installation issues
>>> than
>>> hard coding it in the compiler or even if you add reading some
>>> kind of
>>> external file.
>>>
>>> Right now lots of people have to touch code in the same files for
>>> the
>>> driver, always a bad omen and indicator of design flaws and source
>>> of bugs.
>>>
>>> What will happen is that over time, people will chip away at this
>>> problem and in the end you will have some half baked scripting
>>> language
>>> inside of the driver that does exactly the subset of python needed
>>> for
>>> my driver.
>>>
>>> Clang should be a C++/C front end and that's it.
>>>
>>> Let some natural scripting language worrying about gluing other
>>> pieces
>>> together.
>>>
>>> My 2c.
>>>
>>> Reed
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>> -- IMPORTANT NOTICE: The contents of this email and any attachments
>> are confidential and may also be privileged. If you are not the
>> intended recipient, please notify the sender immediately and do not
>> disclose the contents to any other person, use it for any purpose,
>> or store or copy the information in any medium. Thank you.
>>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 21 Oct 2011 22:32:40 +0100
> From: James Molloy <James.Molloy at arm.com>
> Subject: Re: [cfe-dev] alternate clang driver
> To: reed kotler <rkotler at mips.com>
> Cc: "cfe-dev at cs.uiuc.edu" <cfe-dev at cs.uiuc.edu>
> Message-ID:
> <F01D8B85CFF58440B2A13965FBA90CA47375713403 at GEORGE.Emea.Arm.com>
> Content-Type: text/plain; charset=WINDOWS-1252
>
>> I don't buy the C++ is faster that Python argument.
>
> Well it is, and with such a small script you pay the large fixed
> cost of loading the CPython interpreter for almost no runtime.
>
> The fact that the python runtime can boot quicker than you can
> notice on a modern computer doesn't make it fast, it makes it not
> *noticably slow* by the purist definition. It would slow down large
> build systems, and for lots of small compiles may significantly
> increase the build time and load.
> ________________________________________
> From: reed kotler [rkotler at mips.com]
> Sent: 21 October 2011 22:15
> To: James Molloy
> Cc: Alek Paunov; cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] alternate clang driver
>
> I don't buy the C++ is faster that Python argument. It's just a driver
> for a compiler! You could write it in Turing machine primitives and it
> would be super fast on a modern computer. It's not computing the
> strongly connected components of a terabyte sized graph.
>
> I think you will have some kind of scripting component; whether it's
> LUA
> or Python or some hand brewed language format that is read by the
> clang
> driver and then interpreted, that is what you will have when you
> finish
> solving this problem. That is what I meant by all solutions will be
> isomorphic.
>
> Reed
>
> On 10/21/2011 01:56 PM, James Molloy wrote:
>> Hi,
>>
>> Seeing as everyone's putting in their 2cents, here's mine.
>>
>> The problem is that the current Clang driver is not extensible
>> enough, or easily extensible enough. One can argue that a driver
>> doesn't belong in Clang - that's really arguing semantics because
>> the Driver, while living under the clang tree is detached from the
>> rest of Clang and invokes it as subprocesses.
>>
>> My opinion is that the driver should be either:
>>
>> * Pure C++/TableGen with pretty much everything declaratively
>> defined and just some C++ glue. OR
>> * Pure C++, reads some sort of configuration file.
>>
>> The latter allows for distros to more easily adapt Clang without
>> (a) rebuilding it and (b) shoving patches to support their weird
>> directory structure on us.
>>
>> I do *not* think that launching an external scripting language is
>> best for two reasons.
>>
>> Firstly it is slower than pure C++. ("Oh but LuaJIT is fast!", "Oh
>> but Python is fast!", "The driver time doesn't matter!" - it does.
>> Clang has been built around build speed and to clobber all that
>> effort because of laziness in the driver isn't an option IMHO. And
>> interpreters, even LuaJIT, aren't that fast to boot).
>>
>> Secondly because they create an extra dependency which is bad in
>> and of itself IMHO but worse causes real difficulty in the bringup
>> of new, native toolchains. You'd have to somehow cross-compile
>> LuaJIT for your new architecture before you could run a hosted
>> compiler. This is a terrible idea.
>>
>> Reed, to argue that all solutions would be isomorphic to yours is
>> the same as arguing that Python and C are both Turing-complete and
>> so there is no difference in using one over the other.
>>
>> Cheers,
>>
>> James
>> ________________________________________
>> From: cfe-dev-bounces at cs.uiuc.edu [cfe-dev-bounces at cs.uiuc.edu] On
>> Behalf Of Alek Paunov [alex at declera.com]
>> Sent: 21 October 2011 20:46
>> To: Reed Kotler
>> Cc: cfe-dev at cs.uiuc.edu
>> Subject: Re: [cfe-dev] alternate clang driver
>>
>> Hi Reed,
>>
>> I am fully behind your line of thinking, but why not be even one step
>> more "radical" than your first step:
>>
>> XML (or JSON or YAML - some variant of tree with properties as text -
>> never mind, once it is processable) + scripting language which
>> transform
>> the registry to tool invocation parameters.
>>
>> This means just few lines of important scripting code which
>> everyone can
>> modify (in specific cases) and instant understanding of the required
>> data model (because one look at the bundled XML/JSON variants per
>> distribution will be enough for the (even average) developer to
>> realize
>> the actual requirements).
>>
>> I am also long time Linux/Python user, but in my feelings, the best
>> for
>> CLang (because there are other aspects too) at the moment is LuaJIT.
>>
>> Kind Regards,
>> Alek
>>
>> On 21.10.2011 18:51, Reed Kotler wrote:
>>> On 10/21/2011 03:25 AM, David Chisnall wrote:
>>>> On 21 Oct 2011, at 10:30, Jean-Daniel Dupas wrote:
>>>>
>>>>> I'm not sure writing a new driver from scratch is better than
>>>>> trying to externalize the configuration in the current driver.
>>>>>
>>>>> Is there anybody currently working on the universal driver ( http://clang.llvm.org/UniversalDriver.html
>>>>> ) ?
>>>> No one's currently working on it (or, wasn't last week when I
>>>> asked). It's on my to-do list, but keeps getting pushed lower
>>>> down by stuff I actually get paid for...
>>>>
>>>> David
>>>>
>>>> -- Sent from my brain
>>>>
>>> You will see that no matter how you do this, you will ultimately
>>> end up
>>> with an isomorphic solution to what I did.
>>>
>>> You could try and put all the configuration variables in an XML
>>> file.
>>>
>>> That will be like the data structures in my program but harder to
>>> understand when you want to configure things. You can't factor
>>> things
>>> then because it's just a big data file. If you do a lot of
>>> factoring,
>>> you won't be able to understand the file after a while without
>>> building
>>> some tool.
>>>
>>> There are often some tricky things for a given installation, target,
>>> etc. and it's easier to fix this in the driver script than
>>> rebuilding
>>> the front end.
>>>
>>> Dynamic scripting is more natural for handling installation issues
>>> than
>>> hard coding it in the compiler or even if you add reading some
>>> kind of
>>> external file.
>>>
>>> Right now lots of people have to touch code in the same files for
>>> the
>>> driver, always a bad omen and indicator of design flaws and source
>>> of bugs.
>>>
>>> What will happen is that over time, people will chip away at this
>>> problem and in the end you will have some half baked scripting
>>> language
>>> inside of the driver that does exactly the subset of python needed
>>> for
>>> my driver.
>>>
>>> Clang should be a C++/C front end and that's it.
>>>
>>> Let some natural scripting language worrying about gluing other
>>> pieces
>>> together.
>>>
>>> My 2c.
>>>
>>> Reed
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>> -- IMPORTANT NOTICE: The contents of this email and any attachments
>> are confidential and may also be privileged. If you are not the
>> intended recipient, please notify the sender immediately and do not
>> disclose the contents to any other person, use it for any purpose,
>> or store or copy the information in any medium. Thank you.
>>
>
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments
> are confidential and may also be privileged. If you are not the
> intended recipient, please notify the sender immediately and do not
> disclose the contents to any other person, use it for any purpose,
> or store or copy the information in any medium. Thank you.
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 21 Oct 2011 14:47:16 -0700
> From: reed kotler <rkotler at mips.com>
> Subject: Re: [cfe-dev] alternate clang driver
> To: James Molloy <James.Molloy at arm.com>
> Cc: "cfe-dev at cs.uiuc.edu" <cfe-dev at cs.uiuc.edu>
> Message-ID: <4EA1E864.6020802 at mips.com>
> Content-Type: text/plain; charset="windows-1252"; format=flowed
>
> It's going to be cached by the OS after the first time it's loaded.
>
> On 10/21/2011 02:32 PM, James Molloy wrote:
>>> I don't buy the C++ is faster that Python argument.
>> Well it is, and with such a small script you pay the large fixed
>> cost of loading the CPython interpreter for almost no runtime.
>>
>> The fact that the python runtime can boot quicker than you can
>> notice on a modern computer doesn't make it fast, it makes it not
>> *noticably slow* by the purist definition. It would slow down large
>> build systems, and for lots of small compiles may significantly
>> increase the build time and load.
>> ________________________________________
>> From: reed kotler [rkotler at mips.com]
>> Sent: 21 October 2011 22:15
>> To: James Molloy
>> Cc: Alek Paunov; cfe-dev at cs.uiuc.edu
>> Subject: Re: [cfe-dev] alternate clang driver
>>
>> I don't buy the C++ is faster that Python argument. It's just a
>> driver
>> for a compiler! You could write it in Turing machine primitives and
>> it
>> would be super fast on a modern computer. It's not computing the
>> strongly connected components of a terabyte sized graph.
>>
>> I think you will have some kind of scripting component; whether
>> it's LUA
>> or Python or some hand brewed language format that is read by the
>> clang
>> driver and then interpreted, that is what you will have when you
>> finish
>> solving this problem. That is what I meant by all solutions will be
>> isomorphic.
>>
>> Reed
>>
>> On 10/21/2011 01:56 PM, James Molloy wrote:
>>> Hi,
>>>
>>> Seeing as everyone's putting in their 2cents, here's mine.
>>>
>>> The problem is that the current Clang driver is not extensible
>>> enough, or easily extensible enough. One can argue that a driver
>>> doesn't belong in Clang - that's really arguing semantics because
>>> the Driver, while living under the clang tree is detached from the
>>> rest of Clang and invokes it as subprocesses.
>>>
>>> My opinion is that the driver should be either:
>>>
>>> * Pure C++/TableGen with pretty much everything declaratively
>>> defined and just some C++ glue. OR
>>> * Pure C++, reads some sort of configuration file.
>>>
>>> The latter allows for distros to more easily adapt Clang without
>>> (a) rebuilding it and (b) shoving patches to support their weird
>>> directory structure on us.
>>>
>>> I do *not* think that launching an external scripting language is
>>> best for two reasons.
>>>
>>> Firstly it is slower than pure C++. ("Oh but LuaJIT is fast!", "Oh
>>> but Python is fast!", "The driver time doesn't matter!" - it does.
>>> Clang has been built around build speed and to clobber all that
>>> effort because of laziness in the driver isn't an option IMHO. And
>>> interpreters, even LuaJIT, aren't that fast to boot).
>>>
>>> Secondly because they create an extra dependency which is bad in
>>> and of itself IMHO but worse causes real difficulty in the bringup
>>> of new, native toolchains. You'd have to somehow cross-compile
>>> LuaJIT for your new architecture before you could run a hosted
>>> compiler. This is a terrible idea.
>>>
>>> Reed, to argue that all solutions would be isomorphic to yours is
>>> the same as arguing that Python and C are both Turing-complete and
>>> so there is no difference in using one over the other.
>>>
>>> Cheers,
>>>
>>> James
>>> ________________________________________
>>> From: cfe-dev-bounces at cs.uiuc.edu [cfe-dev-bounces at cs.uiuc.edu] On
>>> Behalf Of Alek Paunov [alex at declera.com]
>>> Sent: 21 October 2011 20:46
>>> To: Reed Kotler
>>> Cc: cfe-dev at cs.uiuc.edu
>>> Subject: Re: [cfe-dev] alternate clang driver
>>>
>>> Hi Reed,
>>>
>>> I am fully behind your line of thinking, but why not be even one
>>> step
>>> more "radical" than your first step:
>>>
>>> XML (or JSON or YAML - some variant of tree with properties as
>>> text -
>>> never mind, once it is processable) + scripting language which
>>> transform
>>> the registry to tool invocation parameters.
>>>
>>> This means just few lines of important scripting code which
>>> everyone can
>>> modify (in specific cases) and instant understanding of the required
>>> data model (because one look at the bundled XML/JSON variants per
>>> distribution will be enough for the (even average) developer to
>>> realize
>>> the actual requirements).
>>>
>>> I am also long time Linux/Python user, but in my feelings, the
>>> best for
>>> CLang (because there are other aspects too) at the moment is LuaJIT.
>>>
>>> Kind Regards,
>>> Alek
>>>
>>> On 21.10.2011 18:51, Reed Kotler wrote:
>>>> On 10/21/2011 03:25 AM, David Chisnall wrote:
>>>>> On 21 Oct 2011, at 10:30, Jean-Daniel Dupas wrote:
>>>>>
>>>>>> I'm not sure writing a new driver from scratch is better than
>>>>>> trying to externalize the configuration in the current driver.
>>>>>>
>>>>>> Is there anybody currently working on the universal driver ( http://clang.llvm.org/UniversalDriver.html
>>>>>> ) ?
>>>>> No one's currently working on it (or, wasn't last week when I
>>>>> asked). It's on my to-do list, but keeps getting pushed lower
>>>>> down by stuff I actually get paid for...
>>>>>
>>>>> David
>>>>>
>>>>> -- Sent from my brain
>>>>>
>>>> You will see that no matter how you do this, you will ultimately
>>>> end up
>>>> with an isomorphic solution to what I did.
>>>>
>>>> You could try and put all the configuration variables in an XML
>>>> file.
>>>>
>>>> That will be like the data structures in my program but harder to
>>>> understand when you want to configure things. You can't factor
>>>> things
>>>> then because it's just a big data file. If you do a lot of
>>>> factoring,
>>>> you won't be able to understand the file after a while without
>>>> building
>>>> some tool.
>>>>
>>>> There are often some tricky things for a given installation,
>>>> target,
>>>> etc. and it's easier to fix this in the driver script than
>>>> rebuilding
>>>> the front end.
>>>>
>>>> Dynamic scripting is more natural for handling installation
>>>> issues than
>>>> hard coding it in the compiler or even if you add reading some
>>>> kind of
>>>> external file.
>>>>
>>>> Right now lots of people have to touch code in the same files for
>>>> the
>>>> driver, always a bad omen and indicator of design flaws and
>>>> source of bugs.
>>>>
>>>> What will happen is that over time, people will chip away at this
>>>> problem and in the end you will have some half baked scripting
>>>> language
>>>> inside of the driver that does exactly the subset of python
>>>> needed for
>>>> my driver.
>>>>
>>>> Clang should be a C++/C front end and that's it.
>>>>
>>>> Let some natural scripting language worrying about gluing other
>>>> pieces
>>>> together.
>>>>
>>>> My 2c.
>>>>
>>>> Reed
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>>
>>> -- IMPORTANT NOTICE: The contents of this email and any
>>> attachments are confidential and may also be privileged. If you
>>> are not the intended recipient, please notify the sender
>>> immediately and do not disclose the contents to any other person,
>>> use it for any purpose, or store or copy the information in any
>>> medium. Thank you.
>>>
>>
>>
>> -- IMPORTANT NOTICE: The contents of this email and any attachments
>> are confidential and may also be privileged. If you are not the
>> intended recipient, please notify the sender immediately and do not
>> disclose the contents to any other person, use it for any purpose,
>> or store or copy the information in any medium. Thank you.
>>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 21 Oct 2011 22:47:16 +0100
> From: David Chisnall <csdavec at swan.ac.uk>
> Subject: Re: [cfe-dev] alternate clang driver
> To: reed kotler <rkotler at mips.com>
> Cc: James Molloy <James.Molloy at arm.com>, "cfe-dev at cs.uiuc.edu"
> <cfe-dev at cs.uiuc.edu>
> Message-ID: <72754025-03E2-4008-B22A-8F3749FC0783 at swan.ac.uk>
> Content-Type: text/plain; charset=us-ascii
>
> On 21 Oct 2011, at 22:15, reed kotler wrote:
>
>> I don't buy the C++ is faster that Python argument. It's just a
>> driver
>> for a compiler! You could write it in Turing machine primitives and
>> it
>> would be super fast on a modern computer. It's not computing the
>> strongly connected components of a terabyte sized graph.
>
> The issue is start-up time. It takes longer to launch the python
> process than it does for the entire compilation and code generation
> process to happen on small C files at -O0.
>
>> I think you will have some kind of scripting component; whether
>> it's LUA
>> or Python or some hand brewed language format that is read by the
>> clang
>> driver and then interpreted, that is what you will have when you
>> finish
>> solving this problem. That is what I meant by all solutions will be
>> isomorphic.
>
>
> I disagree. The number of things that different targets need are
> relatively limited. The vast majority can get away with specifying
> default include paths, crt*.o locations, ld / as locations, and
> target triple. If that solves 99% of cases, then it's worth doing
> that and leaving some external driver for the more complex weird
> cases.
>
> Adding a dependency on Python (or Lua, or what other buzzword
> scripting language that you favour this week) for invoking an
> [Objective-]C[++] compiler seems to redefine overkill.
>
> David
>
>
> ------------------------------
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
> End of cfe-dev Digest, Vol 52, Issue 118
> ****************************************
More information about the cfe-dev
mailing list