On Tue, 2009-01-06 at 13:13 -0800, Zack Rusin wrote: > On Tuesday 06 January 2009 16:00:48 keithw wrote: > > On Tue, 2009-01-06 at 04:26 -0800, PLUG GULP wrote: > > > I think if it is limited to using EC++ then that will act as a guideline > > > too. > > > > > > ~Plug. > > > > > > On Tue, Jan 6, 2009 at 12:33 AM, Zack Rusin <za...@vmware.com> wrote: > > > > On Monday 05 January 2009 17:23:40 Ian Romanick wrote: > > > >> 2. Linking with C++ libraries causes problems with applications. > > > >> > > > >> So far, a fair portion of my GLSL compiler work has been re-creating a > > > >> C++-like object heirarchy and management system. Frankly, the code > > > >> would be much better (for all definitions of better) if I could just > > > >> use C++. > > > >> > > > >> Has issue #2 been resolved? I recall that, for example, if ID's > > > >> Quake3 binary dynamically linked with a library that dynamically > > > >> linked with a different version of libstdc++, it would explode. Is > > > >> that still the case? If this is still a problem, will it affect LLVM > > > >> usage in Mesa? > > > > > > > > LLVM is a bunch of static libs so we can easily impose stdc++ version > > > > on them that Mesa would be fine with. So LLVM will be ok. > > > > If different versions of stdc++ are a worry, I'd suggest writing a > > > > super simple GL app that links to libstdc++5 and then link GL to > > > > libstdc++6 and seeing what happens (even if it burns I honestly think > > > > that a disclaimer saying that 10 year old apps that link to libstdc++5 > > > > won't work with newest Mesa without recompiling is not a huge issue) > > > > Oh, and from what you wrote it sounds like, at least right now, you > > > > don't need stdc++. > > > > Unfortunately LLVM is C++ so it's harder to argue that we should exclude > > it. But I still think we should, mainly because C++ usage always > > spirals out of control into the nastiest steaming pile of poo. > > Everybody always says "oh, of course it can be bad, but we'll stick to a > > lovely subset that is purest gold, it'll make life so good, and we'll > > never, never up the dosage". > > > > But it's a drug that addles the mind, and like it or not, once you start > > you're hooked. One day it's a little operator overloading, the next > > it's some eminently reasonable STL usage, and before you know it, > > there's all sorts of shit all over the place and no way to escape. > > I don't think that's true. Qt is an excellent example. Qt usage of C++ stayed > the same pretty much from the start and whether one likes C++ or not I think > everyone can agree that Qt's API is just beautiful. It's simply a matter of a > well defined and strict review policy which we could probably use anyway.
I'm open to ideas on improving the review process. I do read most patches as they are posted in the commit messages & send comments on occasion, but I'm sure there's scope for more. I'm not fond of a work flow where the reviewer is responsible for pulling the patch out of email and getting it into git. I don't know if it's a tool problem, but it seems to chew up unreasonable amounts of my time whenever I've tried to work that way. Maybe better tools would help, but I'm sceptical. Have you got a suggestion on how to integrate reviews better with the general Mesa process? Keith ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
