[SAC] GDAL buildslave on buildtest operational

The buildtest slave is now identical to the one in buildbot, which could be switched off and perhaps the build area erased to free some disk space. I did not do this yet.

It seems that there was no ticket on this task, but it's done now. I installed new swig (1.3.36 on top of old one from a RPM into /usr/), mono (from RPMs copied from buildbot), netcdf (into /usr/local), python setuptools (where ever it goes).

Regards,

Ari

--
Prof. Ari Jolma
Environmental Management Information Technology
Teknillinen Korkeakoulu / Helsinki University of Technology
tel: +358 9 4511 address: POBox 5300, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://geoinformatics.tkk.fi

On Mon, Nov 17, 2008 at 10:49 PM, Ari Jolma <ari.jolma@tkk.fi> wrote:

I installed new swig (1.3.36 on top of old one from a RPM into /usr/),

I hope it won't break the GRASS SWIG interface :slight_smile:
Next Saturday we'll know then the binaries are compiled...

Best,
Markus

Ari Jolma wrote:

The buildtest slave is now identical to the one in buildbot, which could be switched off and perhaps the build area erased to free some disk space. I did not do this yet.

Ari,

Yes, please cleanup the telascience-quick, telascience-full and
telascience-stable build slave as soon as is convenient.

It seems that there was no ticket on this task, but it's done now. I installed new swig (1.3.36 on top of old one from a RPM into /usr/), mono (from RPMs copied from buildbot), netcdf (into /usr/local), python setuptools (where ever it goes).

Good work!

Looking at the the buildtest-full configure report I see it does not include,
but might benefit from, Xerces, HDF4, mysql and geos support. It might
also be nice if the configurations for -quick and -full were somewhat
distinct. Perhaps -quick could aim for a somewhat minimalist configuration
and -full could aim to include as many options as practical? That way we
can test "graceful fallback" - for instance one with geos, one without.
One with curl, one without.

I guess these details might be better pursued on the gdal-dev list.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

Frank Warmerdam kirjoitti:

Looking at the the buildtest-full configure report I see it does not include,
but might benefit from, Xerces, HDF4, mysql and geos support. It might
also be nice if the configurations for -quick and -full were somewhat
distinct. Perhaps -quick could aim for a somewhat minimalist configuration
and -full could aim to include as many options as practical? That way we
can test "graceful fallback" - for instance one with geos, one without.
One with curl, one without.

I guess these details might be better pursued on the gdal-dev list.

Some background for the gdal-dev list: The telascience_* buildslave is replaced with buildtest_* ones, which reside in a separate computer (xblade11). "Telascience" slaves (actually slave in xblade14-2) do not run any more.

The buildtest machine has now netcdf, hdf4, xerces, geos support. The configure is still the same as what was in "telascience" slave and it is similar in quick and full builds. The --without flags will be added later to the quick build slave.

Xerces is 3.0.0, which causes some problems with autotest: http://trac.osgeo.org/gdal/ticket/2617

MySQL and PostGIS (buildtest has PostgreSQL but not PostGIS) support and tests will be added later.

Regards,

Ari

Best regards,

--
Prof. Ari Jolma
Environmental Management Information Technology
Teknillinen Korkeakoulu / Helsinki University of Technology
tel: +358 9 4511 address: POBox 5300, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://geoinformatics.tkk.fi