[Scummvm-devel] About announcing backend changes & build machine

Oystein Eftevaag wintermute at geheb.com
Tue Jan 1 22:47:16 CET 2008


Ditto for the iPhone toolchain, this sounds like it could be quite helpful.

We use a similar system at work, where each commit to trunk or certain 
branches
will trigger the build farm to build all (or a specified subset) of the 
projects/configurations
and then emailing the committer if one of them breaks, which has been 
really helpful in
making sure that if something breaks, it doesn't stay broken for long.


--
Oystein/Vinterstum

Joost Peters wrote:
> Sounds like a good idea to me.
> I'd be happy to set up the PSP toolchain and required libraries on such 
> a machine, should it ever materialize.
>
> Regards,
> Joost
>
>
> Max Horn schreef:
>   
>> Hi folks,
>>
>> we have so many ports, yet so few porters. Whenever I or somebody  
>> make a change to the backends API, that often causes backends to  
>> break. Either the compilation breaks, or the functionality (in a  
>> sense, the latter is worse, because it can go unnoticed).
>>
>> In the past, we (esp. me) often still made those changes, and did not  
>> always inform porters actively about this. That was and is bad. So,  
>> for the future, we'll try to be a bit more vocal about such changes.  
>> They'll still happen, though: Our philosophy there really is a bit  
>> similar to the Linux kernel one, where we prefer to replace bad APIs  
>> by better ones instead of trying to follow the compatibility road  
>> like Microsoft does. (Note that this is not meant to imply either  
>> approach is "better", both have their pros and cons).
>> However, we will try to notify porters more actively about changes  
>> they may have to make and why, and even warn them a bit beforehand if  
>> possible. I am not yet quite sure how that will work, but we'll try  
>> our best.
>>
>> One problem with at least keeping ports compiling is that it's  
>> difficult for most of us to test that, as not all of us have all the  
>> required (cross) compilers setup.
>>
>> So, wouldn't it be cool if we had a build server on which we setup  
>> cross compile chains for as many systems as we can?
>>
>> This would allow multiple things:
>> * Generate automatic daily builds for all these platforms (with some  
>> extra work, the resulting binaries need to be "packaged) after all)
>> * a nice build status web page (like e.g. <http://www.kegel.com/ 
>> crosstool/crosstool-0.43/buildlogs/>)
>> * optionally, a "trigger rebuild now" feature, which one can use to  
>> get an immediate build test (password protected, of course).
>>
>> For this, it would be really nice if all porters could take something  
>> like 15 minutes and add at least some minimal information about how  
>> their port is built to <http://wiki.scummvm.org/index.php/ 
>> Compiling_ScummVM> (I am serious about those 15 minutes -- just write  
>> down some keywords, naming the tools you use and maybe an URL. Of  
>> course you are welcome to write more if you feel like it :).
>>
>>
>> Still, as I understand it, with a suitable (Linux?) machine, that  
>> could include
>> * Linux (and other UNIX systems) (see e.g. <http://www.kegel.com/ 
>> crosstool/>),
>> * Windows <http://www.wxwidgets.org/docs/technote/crosscmp.htm>
>> * WinCE <http://wiki.scummvm.org/index.php/Compiling_ScummVM/Windows_CE>
>> * Dreamcast <http://wiki.scummvm.org/index.php/Compiling_ScummVM/ 
>> Dreamcast>
>> * Playstation Portable <http://wiki.scummvm.org/index.php/ 
>> Compiling_ScummVM/PlayStation_Portable>
>> * iPhone <http://wiki.scummvm.org/index.php/Compiling_ScummVM/iPhone>
>>
>> And maybe also these (but I know not enough about how they are  
>> built): GP2x, Nintendo DS, Playstation 2, SymbianOS, Maemo,  
>> XBox360... Potentially helpful: devkitPro <http://www.devkitpro.org/>  
>> which apparently is used by the DS port.
>>
>> I have no idea how the PalmOS port is built. The Symbian port  
>> contains build instructions in its README (somebody volunteering to  
>> put them into the Wiki?) note that the link to the Symbian SDK in it  
>> is outdated), but I am not sure whether it can be built under Linux  
>> (but see also <http://www.symbian.com/developer/techlib/v9.2docs/ 
>> doc_source/faqsdk/faq_0956.html>).
>>
>> Still, even if can only build some ports, it would already be a big  
>> improvement
>>
>>
>> Things required for this:
>> * Getting a server: should not be a major issue: we have some money,  
>> and maybe we can even find a sponsor for this.
>> * Setting it up: This would probably require some help from the resp.  
>> porters (at least to test the build chains, ideally also to help  
>> setting them up).
>> * Maintain it: If a porter switches to a new tool chain, we'll have  
>> to update, but my hope is that otherwise, this machine would not  
>> require that much maintenance, and that we could find some members of  
>> the team willing to have an eye on it.
>>
>> Thoughts, comments, remarks, criticism, volunteers,... ? :-)
>>
>>
>> Bye,
>> Max
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Scummvm-devel mailing list
>> Scummvm-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>>
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>   





More information about the Scummvm-devel mailing list