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

[Ruben Van Boxem]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111111/f5d2d64f/attachment.html>