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

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

Oi,

Ok, I will use git as for my daily work, and submit my code to svn if
I need a global feedback.

I have solved the problem with architecture, but now I get the following
syntax error in the pygame code:

rc/transform.c:57: error: syntax error before ‘_state’
src/transform.c:58: warning: initialization makes integer from pointer without a cast src/transform.c:59: error: ‘filter_shrink_X_ONLYC’ undeclared here (not in a function) 
src/transform.c:59: warning: excess elements in scalar initializer
src/transform.c:59: warning: (near initialization for ‘_state’)
src/transform.c:60: error: ‘filter_shrink_Y_ONLYC’ undeclared here (not in a function) 
src/transform.c:60: warning: excess elements in scalar initializer
src/transform.c:60: warning: (near initialization for ‘_state’)
src/transform.c:61: error: ‘filter_expand_X_ONLYC’ undeclared here (not in a function) 
src/transform.c:61: warning: excess elements in scalar initializer
src/transform.c:61: warning: (near initialization for ‘_state’)
src/transform.c:62: error: ‘filter_expand_Y_ONLYC’ undeclared here (not in a function) 
src/transform.c:62: warning: excess elements in scalar initializer
src/transform.c:62: warning: (near initialization for ‘_state’)
src/transform.c:62: warning: data definition has no type or storage class 
src/transform.c: In function ‘surf_scalesmooth’:
src/transform.c:1416: warning: passing argument 3 of ‘scalesmooth’ from incompatible pointer type 
src/transform.c: In function ‘surf_get_smoothscale_backend’:
src/transform.c:1437: error: request for member ‘filter_type’ in something not a structure or union 
src/transform.c: In function ‘surf_set_smoothscale_backend’:
src/transform.c:1443: warning: initialization from incompatible pointer type src/transform.c:1497: error: ‘filter_type’ undeclared (first use in this function) src/transform.c:1497: error: (Each undeclared identifier is reported only once 
src/transform.c:1497: error: for each function it appears in.)
src/transform.c: In function ‘inittransform’:
src/transform.c:2739: warning: assignment from incompatible pointer type
lipo: can't figure out the architecture type of: /var/tmp//cc47AiT3.out
error: command 'gcc' failed with exit status 1

Slu



On 3-mei-09, at 07:48, Nirav Patel wrote:


I personally found/find it useful to use a personal git repo, and use
git-svn to stay up to date with the Pygame SVN.  You can use "git svn
rebase" to keep your repo up to date with upstream and then commit
with "git svn dcommit" when you have code that others can
use/test/hack.

There is a decent guide for using git-svn with github here:
http://www.fnokd.com/2008/08/20/mirroring-svn-repository-to-github/

That is also useful so you have a repo to work in until 1.9 is
released and you can start committing to Pygame SVN.

Nirav
On Sun, May 3, 2009 at 1:10 AM, René Dudfield <renesd@xxxxxxxxx> wrote: 
Hi,

more below...
On Sun, May 3, 2009 at 2:50 PM, el lauwer <el.lauwer@xxxxxxxxx> wrote: 

Oi,

I am installing the latest version of pygame on svn,
so I can start coding on my camera module. I am
installing it under virtualenv so I can keep using
the stable pygame release for my current games.

1)
I recently reseaved a svn account for the pygame
svn repository. How do you sugest I use this account
during the development prossess, should I use it to
commit all my changes to the main brange, or should
I make a personal brange just for my work on the
camera module. Can I use my github account instead,
if so, what must I do with the changes and bug
fixel to the main pygame development brange.
You might want to work on the main trunk, or not... depending on a number of 
things.
Either a separate branch or in your git hub is probably a good way to go. If you put things in svn, then it's easier for some of the pygame developers to watch your work, and maybe even make changes. However it's up to you.
Best to merge your work in occasionally into a svn branch at least. Or send the mailing list a link to your work when you've committed something 
you'd like people to look at or merge in.
Then when your work is getting along, talk about merging it into the trunk with the mailing list and other developers. If no one has changed any of 
the files you have changed, then it's probably ok.
Working in the trunk lets you take advantage of some other things... like the build bots which build on mac/win python2.4 python2.5 python2.6 and run 
the tests for you.  So it can save you a lot of testing work.
Say you wanted to make some changes to surface.c and a bunch of others that aren't part of the camera module directly, and didn't commit to trunk for a few weeks... there's a good chance someone else might make changes to those 
files.
As long as you communicate with other devs what your working on it should be 
fine.