On Mon, Mar 10, 2008 at 3:30 PM, Marcus von Appen <[EMAIL PROTECTED]> wrote: > Many small devices ship with rather slim compilers, which often either > do not support C++ or use e.g. the 2.95 G++ backend, which is known to > be not the best ;-). > any small devices pygame supports that are that way? my understanding with the gp2x and the nokia are that they have perfectly fine c++ support through GCC (though I don't build for them so I don't really know)
> I do not say, let's drop agg, but please keep it optional and seperate > it in a way we can build the rest of the modules still with a C > compiler. Changing the whole build system to C++ would be a bad idea in > my opinion and really limits it. > Gotcha. Except for the "optional" part, I agree with all that. In my mind I was imagining that agg and the agg using files would be c++ but declare some extern "C" functions that all the actual extension code would call, and the extension code would compile with the C compilers. I still seriously doubt that requiring a C++ compiler to build pygame would be any noticeable problem or difficulty on any platform pygame is currently built for. > Besides that there's only the 2.4 version of agg we can stick to, which > is another bad thing due to features and stuff later versions (will) > have. But I guess we just have to live with it then. > I can see how that would be a bit scary - but as it has turned out, Maxim has done almost no developing on the 2.5 code (I think he got a new job making HW accelerated vector and compositing stuff), so 2.4 is very complete and just as good as 2.5. If, however, 2.5 ends up getting something neat and cool, I'm sure Maxim would be willing to license the code differently for the sake of inclusion in an open source lib like pygame (he says he's open to that on his news page) > I do not really get what you say here, but anything mentioned above > (scoping, declare, bool) is also covered by C compilers implementing the > C90/C99 subsets (so nearly any except the really old ones and the MS C > compilers up to at least VS.NET 2005) :-). > I was saying that for C code, C++ compilers are the most portable and consistent. Using C compilers (and not C++ ones) causes portability issues now for pygame. In particular visual studio compiling has been broken in svn a small number of times by code that expected those C subsets to be supported. But that is really kind of small beans compared to the core question for me - which is how will using C++ as part of the pygame build make "everything just a bit harder"?
