[cfe-dev] RFC: Clang driver redesign (round 2)

[reed kotler]

Another requirement for the new driver should be "how are you going to 
test the damn thing"?
That should factor into the design.

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.

Something more involved where you can provide answers to certain 
questions the driver will ask of the environment.

This is especially important considering the various platforms and targets.

On 11/11/2011 09:27 AM, Ruben Van Boxem wrote:
> 2011/11/9 Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>>
>
>     Yes, I also think that is really annoying and should be fixed.
>      Why does fixing it require a new driver?
>
>     -Chris
>
>     On Nov 9, 2011, at 7:02 AM, Christopher Jefferson
>     <chris at bubblescope.net <mailto:chris at bubblescope.net>> wrote:
>
>     >
>     > On 8 Nov 2011, at 21:48, Chris Lattner wrote:
>     >
>     >> On Nov 8, 2011, at 3:23 AM, James Molloy wrote:
>     >>> Thanks for all the replies. I've kind of summarised the main
>     points of
>     >>> contest so far below and tried to group supporters and
>     opponents. If
>     >>> I've grouped you incorrectly, please don't take it slanderously :)
>     >>
>     >> Just MHO:
>     >>
>     >>> "To GCC or not to GCC, that is the question"
>     >>> ============================================
>     >>>
>     >>> +Doug Gregor, Miles Bader
>     >>> -Sean Hunt, Christopher Jefferson, Andrew Trick
>     >>>
>     >>> There is differing opinion on the amount of GCC compatability
>     clang
>     >>> should offer. A lot of examples and arguments have been given,
>     but I
>     >>> see one conclusion - the driver should not be pinned to anything.
>     >>
>     >> 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.
>     >>
>     >> However, the challenge then becomes "why would anyone use the
>     'nice' one"?
>     >
>     > Ease of use.
>     >
>     > I see stories like this over and over again when teaching students.
>     >
>     > $ cat test.cc
>     > #include <iostream>
>     >
>     > int main(void)
>     > {
>     >  int i;
>     >  std::cout << i;
>     > }
>     > $ clang test.cc
>     > Undefined symbols for architecture x86_64:
>     >  "std::ios_base::Init::Init()", referenced from:
>     >      ___cxx_global_var_init in t-vtk1TB.o
>     >  "std::ios_base::Init::~Init()", referenced from:
>     >      ___cxx_global_var_init in t-vtk1TB.o
>     >  "std::cout", referenced from:
>     >      _main in t-vtk1TB.o
>     >  "std::ostream::operator<<(int)", referenced from:
>     >      _main in t-vtk1TB.o
>     > ld: symbol(s) not found for architecture x86_64
>     > clang: error: linker command failed with exit code 1 (use -v to
>     see invocation)
>     > < wander off and ask someone why the code isn't compiling >
>     > $ clang++ test.cc
>     > $ ./a.out
>     > 1872097369
>     > < wander off to ask why the code isn't working. Get told to
>     enable warnings >
>     > $ clang++ test.cc -Wall
>     > t.cc:6:16: warning: variable 'i' is uninitialized when used here
>     >      [-Wuninitialized]
>     >  std::cout << i;
>     >               ^
>     > t.cc:5:8: note: initialize the variable 'i' to silence this warning
>     >  int i;
>     >       ^
>     >        = 0
>     > 1 warning generated.
>     > < grumbles, add the initialisation, code works>
>     >
>     > 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.
>     >
>     >
>     > Chris
>
>
> 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.
>
> Or am I completely rambling?
>
> Ruben
>
>
>     _______________________________________________
>     cfe-dev mailing list
>     cfe-dev at cs.uiuc.edu <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111111/0ea946d8/attachment.html>