[GRASS5] 5.7: new 'fakestart' concept with demolocation

Hi,

upon an idea of Radim I have added a small (68k) demolocation
into the 5.7 source code directory.
The 'fakestart' session is now using this demolocation to
generate the HTML documentation (MAN docs derived from that).

Example:
cd vector/v.hull
make
[...]
GISRC=/home/neteler/soft/57grass_cvsexp/dist.i686-pc-linux-gnu/demolocation/.grassrc57 GISBASE=/home/neteler/soft/57grass_cvsexp/dist.i686-pc-linux-gnu PATH=/home/neteler/soft/57grass_cvsexp/dist.i686-pc-linux-gnu/bin:$PATH LD_LIBRARY_PATH=":/home/neteler/soft/57grass_cvsexp/dist.i686-pc-linux-gnu/lib" /home/neteler/soft/57grass_cvsexp/dist.i686-pc-linux-gnu/bin/v.hull --html-description | grep -v '</body>' > v.hull.tmp.html ; true
echo "<HR>" >> v.hull.tmp.html
echo "<P><a href=index.html>Help Index</a>" >> v.hull.tmp.html
echo "</body></html>" >> v.hull.tmp.html
mkdir -p /home/neteler/soft/57grass_cvsexp/dist.i686-pc-linux-gnu/docs/html
mv -f v.hull.tmp.html /home/neteler/soft/57grass_cvsexp/dist.i686-pc-linux-gnu/docs/html/v.hull.html
install *.png *.jpg /home/neteler/soft/57grass_cvsexp/dist.i686-pc-linux-gnu/docs/html 2> /dev/null ; true

The visible change here is that GISRC is set. If this works acceptable I'll
remove all the

fakestart = getenv( "GRASS_FAKE_START" );
etc

cruft from the GRASS libs.

This approach seems to be less intrusive (as libs are no longer affected) and
hopefully less fragile as well in case of library changes.
Hopefully also
http://intevation.de/rt/webrt?serial_num=2708
will be cured at the same time.

Future:
This 'demolocation' could be populated with data and then used for
some regression tests.

Markus

Markus Neteler wrote:

upon an idea of Radim I have added a small (68k) demolocation
into the 5.7 source code directory.
The 'fakestart' session is now using this demolocation to
generate the HTML documentation (MAN docs derived from that).

AFAICT, this won't work if the user building GRASS doesn't own the
source tree, due to G__mapset_permissions().

--
Glynn Clements <glynn@gclements.plus.com>

On Fri, Nov 26, 2004 at 10:03:05PM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> upon an idea of Radim I have added a small (68k) demolocation
> into the 5.7 source code directory.
> The 'fakestart' session is now using this demolocation to
> generate the HTML documentation (MAN docs derived from that).

AFAICT, this won't work if the user building GRASS doesn't own the
source tree, due to G__mapset_permissions().

Mhh.
Maybe, if-user-doesnt-own-source-tree then do this in /tmp?
No idea.

I'm open to different solutions if really needed.

Markus

On Mon, Nov 29, 2004 at 02:04:18PM +0100, Markus Neteler wrote:

On Fri, Nov 26, 2004 at 10:03:05PM +0000, Glynn Clements wrote:
>
> Markus Neteler wrote:
>
> > upon an idea of Radim I have added a small (68k) demolocation
> > into the 5.7 source code directory.
> > The 'fakestart' session is now using this demolocation to
> > generate the HTML documentation (MAN docs derived from that).
>
> AFAICT, this won't work if the user building GRASS doesn't own the
> source tree, due to G__mapset_permissions().

Thinking again:

Note that the demolocation is first installed into dist.$ARCH,
then this one is used (not the one of the source code).
So: in case dist.$ARCH is not writable, the compilation won't
work at all.

grep GISRC ~/grass57/include/Make/Rules.make
        GISRC=$(GISBASE)/demolocation/.grassrc${GRASS_VERSION_MAJOR}${GRASS_VERSION_MINOR} \

I feel that the above mentioned potential problem with
G__mapset_permissions() doesn't exist (maybe I am wrong).

Markus

Markus Neteler wrote:

> > > upon an idea of Radim I have added a small (68k) demolocation
> > > into the 5.7 source code directory.
> > > The 'fakestart' session is now using this demolocation to
> > > generate the HTML documentation (MAN docs derived from that).
> >
> > AFAICT, this won't work if the user building GRASS doesn't own the
> > source tree, due to G__mapset_permissions().

Thinking again:

Note that the demolocation is first installed into dist.$ARCH,
then this one is used (not the one of the source code).

I've since noticed that. As the user running "make" will own the copy,
there shouldn't be a problem.

--
Glynn Clements <glynn@gclements.plus.com>

Future:
This 'demolocation' could be populated with data and then used for
some regression tests.

suggestion for population-

we include an ASCII file with x,y,... point data.
v.in.ascii
v.surf.?
r.contour

would create test point, vector lines, and raster maps from only a small
file in the main tarball. maybe bug points from spearfish or something.

Hamish

Hamish wrote:

Future:
This 'demolocation' could be populated with data and then used for
some regression tests.

suggestion for population-

we include an ASCII file with x,y,... point data. v.in.ascii
v.surf.?
r.contour

would create test point, vector lines, and raster maps from only a small
file in the main tarball. maybe bug points from spearfish or something.

We could also generate random vector maps (v.random,v.delaunay)
convert them to raster, do the same analysis in raster and vector
and compare results.

Radim

>>Future:
>>This 'demolocation' could be populated with data and then used for
>>some regression tests.
>
> suggestion for population-
>
> we include an ASCII file with x,y,... point data.
> v.in.ascii
> v.surf.?
> r.contour
>
> would create test point, vector lines, and raster maps from only a
> small file in the main tarball. maybe bug points from spearfish or
> something.

We could also generate random vector maps (v.random,v.delaunay)
convert them to raster, do the same analysis in raster and vector
and compare results.

maybe that would catch more errors, but would it be harder to reproduce
bugs then?

Hamish

>>Future:
>>This 'demolocation' could be populated with data and then used for
>>some regression tests.
>
> suggestion for population-
>
> we include an ASCII file with x,y,... point data.
> v.in.ascii
> v.surf.?
> r.contour
>
> would create test point, vector lines, and raster maps from only a small
> file in the main tarball. maybe bug points from spearfish or something.

We could also generate random vector maps (v.random,v.delaunay)
convert them to raster, do the same analysis in raster and vector
and compare results.

I didn't catch your "also", ... of course we could do both.

Hamish