<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Another requirement for the new driver should be "how are you going
to test the damn thing"?<br>
That should factor into the design.<br>
<br>
I think some kind of simulation mode, i.e. like "make -n" or "make
--just-print") should exist so that you can make test cases for
this. Then you can capture expected output , etc.<br>
<br>
Something more involved where you can provide answers to certain
questions the driver will ask of the environment. <br>
<br>
This is especially important considering the various platforms and
targets.<br>
<br>
On 11/11/2011 09:27 AM, Ruben Van Boxem wrote:
<blockquote
cite="mid:CALc40c9BpTBnXWijSWPjNpK5ouQca-0t8cVU5XswPrw2twAH+Q@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="gmail_quote">2011/11/9 Chris Lattner <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:clattner@apple.com">clattner@apple.com</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Yes, I also think that is really annoying and should be fixed.
Why does fixing it require a new driver?<br>
<span class="HOEnZb"><font color="#888888"><br>
-Chris<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
On Nov 9, 2011, at 7:02 AM, Christopher Jefferson <<a
moz-do-not-send="true"
href="mailto:chris@bubblescope.net">chris@bubblescope.net</a>>
wrote:<br>
<br>
><br>
> On 8 Nov 2011, at 21:48, Chris Lattner wrote:<br>
><br>
>> On Nov 8, 2011, at 3:23 AM, James Molloy wrote:<br>
>>> Thanks for all the replies. I've kind of
summarised the main points of<br>
>>> contest so far below and tried to group
supporters and opponents. If<br>
>>> I've grouped you incorrectly, please don't
take it slanderously :)<br>
>><br>
>> Just MHO:<br>
>><br>
>>> "To GCC or not to GCC, that is the question"<br>
>>> ============================================<br>
>>><br>
>>> +Doug Gregor, Miles Bader<br>
>>> -Sean Hunt, Christopher Jefferson, Andrew
Trick<br>
>>><br>
>>> There is differing opinion on the amount of
GCC compatability clang<br>
>>> should offer. A lot of examples and arguments
have been given, but I<br>
>>> see one conclusion - the driver should not be
pinned to anything.<br>
>><br>
>> This is an absolute must-have. I guess I'm not
opposed to having a *second* driver that is "nicer"
somehow than the existing one, but we cannot give up GCC
compatibility in the main clang driver.<br>
>><br>
>> However, the challenge then becomes "why would
anyone use the 'nice' one"?<br>
><br>
> Ease of use.<br>
><br>
> I see stories like this over and over again when
teaching students.<br>
><br>
> $ cat test.cc<br>
> #include <iostream><br>
><br>
> int main(void)<br>
> {<br>
> int i;<br>
> std::cout << i;<br>
> }<br>
> $ clang test.cc<br>
> Undefined symbols for architecture x86_64:<br>
> "std::ios_base::Init::Init()", referenced from:<br>
> ___cxx_global_var_init in t-vtk1TB.o<br>
> "std::ios_base::Init::~Init()", referenced from:<br>
> ___cxx_global_var_init in t-vtk1TB.o<br>
> "std::cout", referenced from:<br>
> _main in t-vtk1TB.o<br>
> "std::ostream::operator<<(int)", referenced
from:<br>
> _main in t-vtk1TB.o<br>
> ld: symbol(s) not found for architecture x86_64<br>
> clang: error: linker command failed with exit code 1
(use -v to see invocation)<br>
> < wander off and ask someone why the code isn't
compiling ><br>
> $ clang++ test.cc<br>
> $ ./a.out<br>
> 1872097369<br>
> < wander off to ask why the code isn't working.
Get told to enable warnings ><br>
> $ clang++ test.cc -Wall<br>
> t.cc:6:16: warning: variable 'i' is uninitialized
when used here<br>
> [-Wuninitialized]<br>
> std::cout << i;<br>
> ^<br>
> t.cc:5:8: note: initialize the variable 'i' to
silence this warning<br>
> int i;<br>
> ^<br>
> = 0<br>
> 1 warning generated.<br>
> < grumbles, add the initialisation, code works><br>
><br>
> I think it would be worth trying to reduce the pain
here, for a beginner programmer. I'll admit I don't know
the best way of doing that.<br>
><br>
><br>
> Chris<br>
</div>
</div>
</blockquote>
<div><br>
Loosely related but not completely orthogonal; does LLVM
provide an abstracted fool-proof API/Class to gather
commandline arguments? Seeing that it provides a bunch of
executables and lends itself to fronted development, I would
think it should, something simple that reads all the
arguments, converts them to some generic/specialized
"commandlineoptions" structure, that the frontend can
transparently use to get it's internal options from.<br>
<br>
Or am I completely rambling?<br>
<br>
Ruben<br>
<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div class="HOEnZb">
<div class="h5">
_______________________________________________<br>
cfe-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>