Re: [pygame] MMX Transform for Win32

["Brian Fisher" <brian@xxxxxxxxxxxxxxxxxxx>]

On Mon, Mar 10, 2008 at 3:30 PM, Marcus von Appen <mva@xxxxxxxxxxxx> 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"?