... and it looks like Lenard has fixed it already too. Latest svn trunk compiles on osx again.
cu, On Mon, May 4, 2009 at 8:03 AM, René Dudfield <ren...@gmail.com> wrote: > hi, > > looks like some changes from the py3k merge that Lenard just did. > > Note, that the build bot last built successfully: revision 2047 > > So you can always check out that revision, that built successfully on osx, > until trunk is fixed. > > > > This is also points out how changes on one platform can easily break other > platforms, and why the buildbot is so awesome. > > > cu, > > > > > On Mon, May 4, 2009 at 1:33 AM, Brian Fisher <br...@hamsterrepublic.com>wrote: > >> 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. >>>>> >>>>> >>> >> >
