My automated build machine is having the same problem on OS X, so I'd say it's nothing wrong with your setup: http://thorbrian.com/pygame/builds.php
On Sun, May 3, 2009 at 12:14 AM, el lauwer <el.lau...@gmail.com> wrote: > 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 <ren...@gmail.com> wrote: >> >>> Hi, >>> >>> more below... >>> >>> On Sun, May 3, 2009 at 2:50 PM, el lauwer <el.lau...@gmail.com> 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. >>> >>> >
