[GRASS-dev] WinGRASS 6.3.0: d.paint.labels, r.cats & p.out.vrml

Hi all,

I’m still building here…
With RC6 build I needed to manually create the following dynamic links, since they failed during the building procedure:

  • d.paint.labels: linked to d.labels
  • r.cats: linked to r.category
  • p.out.vrml: linked to r.out.vrml

I don’t remember exactly, but it seems to me that something has changed. Do we still need those links?
Thanks,

Marco

marco.pasetti@alice.it wrote:

I'm still building here...
With RC6 build I needed to manually create the following dynamic links, since they failed during the building procedure:

- d.paint.labels: linked to d.labels
- r.cats: linked to r.category
- p.out.vrml: linked to r.out.vrml

I don't remember exactly, but it seems to me that something has
changed. Do we still need those links?

I added scripts for those commands, but they weren't back-ported to
6.3.0.

So, you need to copy the scripts from the trunk and put them in the
$GISBASE/scripts directory.

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

Hi Glynn,

thanks. I think I’ll just add those dynamic links as done for RC6, since build procerdure is quite-finished and I prefer to not modifiy the release tarball content.

Marco


Da: Glynn Clements [mailto:glynn@gclements.plus.com]
Inviato: lun 21/04/2008 15.39
A: marco.pasetti@alice.it
Cc: grass-dev@lists.osgeo.org
Oggetto: Re: [GRASS-dev] WinGRASS 6.3.0: d.paint.labels, r.cats & p.out.vrml

marco.pasetti@alice.it wrote:

I’m still building here…
With RC6 build I needed to manually create the following dynamic links, since they failed during the building procedure:

  • d.paint.labels: linked to d.labels
  • r.cats: linked to r.category
  • p.out.vrml: linked to r.out.vrml

I don’t remember exactly, but it seems to me that something has
changed. Do we still need those links?

I added scripts for those commands, but they weren’t back-ported to
6.3.0.

So, you need to copy the scripts from the trunk and put them in the
$GISBASE/scripts directory.


Glynn Clements glynn@gclements.plus.com

marco.pasetti@alice.it wrote:

thanks. I think I'll just add those dynamic links as done for RC6, since
build procerdure is quite-finished and I prefer to not modifiy the
release tarball content.

Links? How do you create links on Windows?

Or are you just copying the executables? That will work; I suppose
that it's a bit wasteful, but ultimately it's negligible compared to
the overall size of GRASS.

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

Glynn,

Links? How do you create links on Windows?
`ln -s -f /usr/local/src/grass-6.3.0RC6/dist.i686-pc-mingw32/bin/d.labels \` `/usr/local/src/grass-6.3.0RC6/dist.i686-pc-mingw32/bin/d.paint.labels`
Marco


Da: Glynn Clements [mailto:glynn@gclements.plus.com]
Inviato: lun 21/04/2008 18.05
A: marco.pasetti@alice.it
Cc: grass-dev@lists.osgeo.org
Oggetto: Re: R: [GRASS-dev] WinGRASS 6.3.0: d.paint.labels, r.cats & p.out.vrml

marco.pasetti@alice.it wrote:

thanks. I think I’ll just add those dynamic links as done for RC6, since
build procerdure is quite-finished and I prefer to not modifiy the
release tarball content.

Links? How do you create links on Windows?

Or are you just copying the executables? That will work; I suppose
that it’s a bit wasteful, but ultimately it’s negligible compared to
the overall size of GRASS.


Glynn Clements glynn@gclements.plus.com

marco.pasetti@alice.it wrote:

>Links? How do you create links on Windows?

ln -s -f /usr/local/src/grass-6.3.0RC6/dist.i686-pc-mingw32/bin/d.labels \
/usr/local/src/grass-6.3.0RC6/dist.i686-pc-mingw32/bin/d.paint.labels

Right; MSys' "ln" just copies the file. For this particular situation,
that's adequate.

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

Glynn:

> >Links? How do you create links on Windows?

Marco:

> ln -s -f
/usr/local/src/grass-6.3.0RC6/dist.i686-pc-mingw32/bin/d.labels \
> /usr/local/src/grass-6.3.0RC6/dist.i686-pc-mingw32/bin/d.paint.labels

Glynn:

Right; MSys' "ln" just copies the file. For this particular situation,
that's adequate.

IIRC, the "trick" posted to the list earlier was that MSys requires you
to use the full path for both the source and the target. The old Makefile
was only using the full path for the target.

(in light of that I was slightly confused as to why you went to the all
the trouble of making scripts for those, I assumed you had a good reason.
note man pages still need to be symlinked/copied to those scripts as the
build report complains)

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Hamish wrote:

Glynn:
> > >Links? How do you create links on Windows?
Marco:
> > ln -s -f
> /usr/local/src/grass-6.3.0RC6/dist.i686-pc-mingw32/bin/d.labels \
> > /usr/local/src/grass-6.3.0RC6/dist.i686-pc-mingw32/bin/d.paint.labels
Glynn:
> Right; MSys' "ln" just copies the file. For this particular situation,
> that's adequate.

IIRC, the "trick" posted to the list earlier was that MSys requires you
to use the full path for both the source and the target. The old Makefile
was only using the full path for the target.

That's how you would normally create symlinks.

Note that the source (i.e. the value of the resulting symlink) is
treated as a verbatim string; it doesn't even have to exist. If you
use a full path, the value of the symlink will be a full path.

It's usual to use relative paths, so that "moving" the directory
works. This isn't limited to actually moving the directory with mv,
but also to changing the filesystem's mount point, exporting and
mounting via NFS, "mount --bind" etc. All of these will break if the
symlink contains an absolute path.

(in light of that I was slightly confused as to why you went to the all
the trouble of making scripts for those,

"all the trouble" is a script containing a single command, e.g.:

  exec d.labels "$@"

The reason is that a script is an ordinary file, which presents fewer
problems on Windows, with archives, etc.

I assumed you had a good reason.
note man pages still need to be symlinked/copied to those scripts as the
build report complains)

Ideally, manual pages should use a ".so" directive rather than
symlinks, e.g.:

  .so man1/d.labels.1

However, this is problematic with GRASS' build system (module
Makefiles don't get to provide their own rules for building manpages).
Also, it won't work for HTML files.

One option is to add a description.html file which simply says to
refer to the documentation for the underlying command.

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