[GRASS5] automatic build script

GRASS GRASS developer
1

Hi,

i have written a short script to automate downloading of the sources,
configure'ing, make'ing and uploading the final binary distribution to a
server in pub/incoming.
I'll check the script into CVS under tools later. This should work from
a crontab entry, but it does not compile like outlined in the compile
instructions (first building wihtout postgresql support, then compiling
nviz separately, then ...).

I have the following changes, which i want to ask your opinion:
- adding a strip target to the Makefile.in
(will be done with find . -type f -exec strip {} \;, as we do not use
install to copy the binaries, this may corrupt all files if you have an
unusual setup, eg. GNU gcc strip in path before system strip, but using
system compiler)
- adding a new target install-strip (this conforms to the usual GNU
targets)
- changing the name of the grass5install.sh script to
grass5_${ARCH}_install.sh, so that it is not overwritten on uploading
different builds and does not conflict with other files on the anon ftp
server. It will be possible to see to which binary tarball the script
belongs.

Another problem is that the name of the source file changes for each
release/CVS snapshot, but the old files are not preserved. This breaks
all scripted builds, e. g. from FreeBSD ports (which does not work
anymore, because the baylor ftp server is down (no route to host)). No
idea how to solve this.

Andreas

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
url: http://mitglied.tripod.de/AndreasLange
mail: Andreas.Lange_at_Rhein-Main.de - A.C.Lange_at_GMX.net

2

Hi Andreas,

On Fri, Jan 11, 2002 at 06:40:50PM +0100, Andreas Lange wrote:

Hi,

i have written a short script to automate downloading of the sources,
configure'ing, make'ing and uploading the final binary distribution to a
server in pub/incoming.

that's great! Thanks a lot for the scripts.

I'll check the script into CVS under tools later. This should work from
a crontab entry, but it does not compile like outlined in the compile
instructions (first building wihtout postgresql support, then compiling
nviz separately, then ...).

I have the following changes, which i want to ask your opinion:
- adding a strip target to the Makefile.in
(will be done with find . -type f -exec strip {} \;, as we do not use
install to copy the binaries, this may corrupt all files if you have an
unusual setup, eg. GNU gcc strip in path before system strip, but using
system compiler)

I think that this can be done much easier (have added yesterday a related
comment to INSTALL:

[...]
A real fast GRASS version (and small binaries) will be created with
LDFLAGS set to "stripping":

CFLAGS="-O3 -mcpu=pentiumpro -Wall" LDFLAGS="-s" ./configure

This LDFLAGS hint I have also added to documents/release_rules.txt

- adding a new target install-strip (this conforms to the usual GNU
targets)
- changing the name of the grass5install.sh script to
grass5_${ARCH}_install.sh, so that it is not overwritten on uploading
different builds and does not conflict with other files on the anon ftp
server. It will be possible to see to which binary tarball the script
belongs.

Yes, I agree. Seems to be too dangerous with the current name convention.

Another problem is that the name of the source file changes for each
release/CVS snapshot, but the old files are not preserved. This breaks
all scripted builds, e. g. from FreeBSD ports (which does not work
anymore, because the baylor ftp server is down (no route to host)). No
idea how to solve this.

Mhhh, the problem is that some mirror sites only provide limited
space. That's why I don't keep the old versions (they are kept at
Baylor site) in grass.itc.it.
I am too lazy to always update the rsync configuration. Any other
possibilities which I don't know?

Markus

3

Markus Neteler wrote:

Hi Andreas,
[...]
I think that this can be done much easier (have added yesterday a related
comment to INSTALL:

[...]
A real fast GRASS version (and small binaries) will be created with
LDFLAGS set to "stripping":

CFLAGS="-O3 -mcpu=pentiumpro -Wall" LDFLAGS="-s" ./configure

This LDFLAGS hint I have also added to documents/release_rules.txt

I knew this already. But the problem is that the target "install-strip"
is impossible to implement if the stripping is done at compile time. I
think it is better to compile without stripping (to make debugging
possible) and to install for the binary distribution with install-strip
(as users usually have no need for debugging symbols).
The "normal" setup is that the programm "install" is used to install the
binary files, and this program has the option "-s" for stripping while
installing.

> Another problem is that the name of the source file changes for each
> release/CVS snapshot, but the old files are not preserved. This breaks
> all scripted builds, e. g. from FreeBSD ports (which does not work
> anymore, because the baylor ftp server is down (no route to host)). No
> idea how to solve this.

Mhhh, the problem is that some mirror sites only provide limited
space. That's why I don't keep the old versions (they are kept at
Baylor site) in grass.itc.it.
I am too lazy to always update the rsync configuration. Any other
possibilities which I don't know?

I think there is no optimal solution. We can not preserve the old
versions as tarballs, it should be possible to re-create them from CVS
anyhow. Perhaps the weekly CVS snapshot should be named always the same,
so that there is no need to update the build script. And we should watch
that the hostnames/paths do not change in future.

Andreas
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
url: http://mitglied.tripod.de/AndreasLange
mail: Andreas.Lange_at_Rhein-Main.de - A.C.Lange_at_GMX.net