I have modified
tools/build_html_index.sh
to generate more compact HTML pages, also with less
redundancy:
re. r36022, d.font.freetype and d.text.freetype should not be on the
no-G_parser() list. perhaps they are failing to run/build on the server
for some other reason?
here they correctly have name:description in the display modules list
like any other script.
On Sun, Feb 22, 2009 at 6:44 AM, Hamish <hamish_b@yahoo.com> wrote:
Markus wrote:
I have modified
tools/build_html_index.sh
..
re. r36022, d.font.freetype and d.text.freetype should not be on the
no-G_parser() list. perhaps they are failing to run/build on the server
for some other reason?
Mhh, no idea. They has only the name of the other (new) module
but no description.
here they correctly have name:description in the display modules list
like any other script.
Here it fails.
Well, I guess that the addition to the list in tools/build_html_index.sh
is rather harmless (but if you don't think so we can revert that).
> re. r36022, d.font.freetype and d.text.freetype should not be on the
> no-G_parser() list. perhaps they are failing to run/build on the server
> for some other reason?
Markus:
Mhh, no idea. They has only the name of the other (new)
module but no description.
> here they correctly have name:description in the display modules list
> like any other script.
Here it fails.
what does 'd.font.freetype --help' say on that machine?
Does the build use freetype compile flag? are d.font and d.text there?
the scripts are just wrappers that do like:
exec d.text "$@"
shrug.
anyway, they aren't active; so we shouldn't advertize them; so I've
added them to the ignore list in the script. problem solved
g.manual still works if anyone is curious.
Well, I guess that the addition to the list in tools/build_html_index.sh
is rather harmless (but if you don't think so we can revert that).
that script is enough of an ugly PITA to follow without more noise...
Hamish
ps- what's up with r.li.daemon? the html page is on the no-G_parser()
list; the Makefile says it's what becomes libgrass_rli.so, and main.c
is named main.c.unused? former frontend to the library or stand-alone
version?
On Wed, Feb 25, 2009 at 10:47 AM, Hamish <hamish_b@yahoo.com> wrote:
Markus wrote:
>> I have modified tools/build_html_index.sh
Hamish:
> re. r36022, d.font.freetype and d.text.freetype should not be on the
> no-G_parser() list. perhaps they are failing to run/build on the server
> for some other reason?
Markus:
Mhh, no idea. They has only the name of the other (new)
module but no description.
> here they correctly have name:description in the display modules list
> like any other script.
Here it fails.
what does 'd.font.freetype --help' say on that machine?
the scripts are just wrappers that do like:
exec d.text "$@"
shrug.
anyway, they aren't active; so we shouldn't advertize them; so I've
added them to the ignore list in the script. problem solved
g.manual still works if anyone is curious.
Perfect
Well, I guess that the addition to the list in tools/build_html_index.sh
is rather harmless (but if you don't think so we can revert that).
that script is enough of an ugly PITA to follow without more noise...
Hamish
ps- what's up with r.li.daemon? the html page is on the no-G_parser()
list; the Makefile says it's what becomes libgrass_rli.so, and main.c
is named main.c.unused? former frontend to the library or stand-alone
version?
In the directory libgrass_rli.6.5.svn.so is used. I assume that main.c.unused
serves as a template (maybe better name it as such?).