[cfe-dev] alternate clang driver
Michael Price - Dev
michael.b.price.dev at gmail.com
Fri Oct 21 17:33:45 PDT 2011
Sorry, stupid phone sent prematurely.
Ultimately, anyone can write whatever scripts they want. I doubt most
people would consider that an acceptable solution for clang itself.
Sent from my iPhone
On Oct 21, 2011, at 7:31 PM, Michael Price - Dev <michael.b.price.dev at gmail.com
> wrote:
> 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