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

Max Horn max at quendi.de
Wed Jan 2 09:39:36 CET 2008

Am 02.01.2008 um 00:28 schrieb Travis Howell:

> I have CCed to Claudio Matsuoka for comments, since he provides our  
> current
> daily builds service.

> From: "Max Horn" <max at quendi.de>
>> 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).
> We already have an automatic builds service provided by Claudio  
> Matsuoka at
> http://www.scummvm.org/daily/

Actually, you can't know this, but: His machine died a few days ago.  
So right now, we are without a build machine. Which is one of the  
things motivating me for my original mail.


>> 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.
> Considering we currently have a daily builds service provided, I'm not
> convinced it is worth paying for server or renting a server.

Since we don't have a daily build service right now, I consider this  
moot ;).

> There are disadvantages to an automated build system too:
> -It tends to break down more easily, when unexpected changes are made.

There are existing off-the-shelf systems for automated build systems  
which we can use. See e.g. the Mozilla Tinderbox. Or <http:// 
cruisecontrol.sourceforge.net/>. The latter even includes remote GUI  
interfaces. Very nifty.

> -It relies on a remote system, which we might not have full control  
> of.

Full control would of course be nice: One of us could host it -- e.g.  
Claudio; I would host it, but then we'd be limited in our bandwidth.  
In fact, bandwidth is a major factor to take into consideration; we  
probably wouldn't want to host those builds directly from the build  
server (besides bandwidth, security has to be taken into account). An  
alternative would be to do what Claudio did, that is, SCP the data  
between the build and the web/FTP server.

Alternatively, we could use a VPS, e.g. at HostEurope (were our  
Forums & Wiki & internal FTP are hosted at anyway), starting at 10  
Euro/month (although we probably would want more than the smallest  
VPS). However, I am not sure this would be sufficient.

> -It relies on a different compiler enviroment, which we might not  
> be able to
> keep as up to date.

I don't understand that point... ? What would be "different" about  
it? Different compared to what?

> -If developers build via different methods, it can be more  
> difficult to
> track down problems caused by the specific compiler enviroment used  
> for
> snapshots.

That's why porters should be involved in setting up the daily builds.  
Although I think what you describe might be a *bonus*, as it would  
help us uncover bugs that might escape our notice otherwise. But of  
course we wouldn't want to be caught by compiler bugs, hence once  
more the desire to involve porters.

> For Windows builds I will stick with manual snapshots, which are  
> usually
> updated a few times daily anyway. So users don't have to deal with  
> automated
> system breaking down, and are provided with Windows binaries based  
> on most
> recent releases of tools.

Fine by me, we were not going to blackmail anybody into anything :)


More information about the Scummvm-devel mailing list