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

[Jean-Daniel Dupas]

Le 11 nov. 2011 à 20:10, reed kotler a écrit :

> 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.
> 

Something like clang -### ?


> On 11/11/2011 09:27 AM, Ruben Van Boxem wrote:
>> 
>> 2011/11/9 Chris Lattner <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> 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
>> 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
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- Jean-Daniel




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