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

[Glynn Clements]

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 at gclements.plus.com>