[Scummvm-devel] About announcing backend changes & build machine
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
will trigger the build farm to build all (or a specified subset) of the
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.
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.
> 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/
>> * 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/
>> * 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/
>> * Playstation Portable <http://wiki.scummvm.org/index.php/
>> * 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/
>> Still, even if can only build some ports, it would already be a big
>> 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,... ? :-)
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> Scummvm-devel mailing list
>> Scummvm-devel at lists.sourceforge.net
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
More information about the Scummvm-devel