[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] MMX Transform for Win32



Slower compilation, less platform support, faster changing ABI, bigger
binaries, and a more complex language.  Compilation of C++ python
extensions is a bit harder on windows too - because mingw & vc don't
share the same ABI (but maybe this has changed with the upcoming 4.x
gcc for mingw, and new VC release).

It's definitely something we need to discuss for the next pygame
releases... weather we choose SDL_gfx, cairo, tinyGL, opencv, or AGG
(or some combination of them).  Note that the SDL_gfx author has
expressed interest in working with us, which is nice.




On Tue, Mar 11, 2008 at 9:46 AM, Brian Fisher <brian@xxxxxxxxxxxxxxxxxxx> wrote:
> 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"?
>