Hi,
we try to compile winGRASS on a colleague's computer (XP),
following
https://trac.osgeo.org/grass/wiki/CompileOnWindows
./mswindows/osgeo4w/package.sh
...
checking for perl... no
...
At this point, MAN is not created, leading to a tar packaging error later.
But:
$ perl -v
This is perl., v5.10.1 built for MSWin32-x86-multi-thread
...
I am suprised that perl isn't detected by configure. Nothing dramatic of course.
Did any other winGRASS builder observe this problem?
Markus
On Tue, Jan 19, 2010 at 5:26 AM, Markus Neteler <neteler@osgeo.org> wrote:
Hi,
we try to compile winGRASS on a colleague's computer (XP),
following
https://trac.osgeo.org/grass/wiki/CompileOnWindows./mswindows/osgeo4w/package.sh
...
checking for perl... no
...At this point, MAN is not created, leading to a tar packaging error later.
But:
$ perl -v
This is perl., v5.10.1 built for MSWin32-x86-multi-thread
...I am suprised that perl isn't detected by configure. Nothing dramatic of course.
Did any other winGRASS builder observe this problem?
Forgot to mention that we installed Perl from ActiveState as in OSGeo4W
we couldn't (surprisingly) find it.
Markus
Markus Neteler wrote:
we try to compile winGRASS on a colleague's computer (XP),
following
https://trac.osgeo.org/grass/wiki/CompileOnWindows./mswindows/osgeo4w/package.sh
...
checking for perl... no
...At this point, MAN is not created, leading to a tar packaging error later.
But:
$ perl -v
This is perl., v5.10.1 built for MSWin32-x86-multi-thread
...I am suprised that perl isn't detected by configure. Nothing
dramatic of course.
No idea why; it's just an AC_PATH_PROG() check; nothing unusual about
it.
Did any other winGRASS builder observe this problem?
I've never noticed it, because man/Makefile silently skips building
the manpages if Perl isn't present (I don't have it on Windows).
Maybe we should use the Python version from 7.0? Many users will want
Python anyhow, whereas Perl is only used for g.html2man.
OTOH, how many Windows users will want nroff manpages?
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, Jan 19, 2010 at 7:20 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
we try to compile winGRASS on a colleague's computer (XP),
following
https://trac.osgeo.org/grass/wiki/CompileOnWindows./mswindows/osgeo4w/package.sh
...
checking for perl... no
...At this point, MAN is not created, leading to a tar packaging error later.
But:
$ perl -v
This is perl., v5.10.1 built for MSWin32-x86-multi-thread
...I am suprised that perl isn't detected by configure. Nothing
dramatic of course.No idea why; it's just an AC_PATH_PROG() check; nothing unusual about
it.Did any other winGRASS builder observe this problem?
I've never noticed it, because man/Makefile silently skips building
the manpages if Perl isn't present (I don't have it on Windows).
That's right but "tar" complains (read: warns) about the missing man
stuff later. Perhaps it has to be conditionalized upon perl presence
as well.
Maybe we should use the Python version from 7.0? Many users will want
Python anyhow, whereas Perl is only used for g.html2man.
Sounds good, we would get rid of a dependency.
OTOH, how many Windows users will want nroff manpages?
Likely 0.001%. It was more for a potential breakage of the packaging
process.
Markus
Glynn wrote:
Maybe we should use the Python version from 7.0? Many users
will want Python anyhow, whereas Perl is only used for
g.html2man.
At this point, my vote, AFA 6.4.0 goes, is to follow the path of
least change. Which is to keep the existing perl script.
OTOH, how many Windows users will want nroff manpages?
or even know how to access them?
Hamish
Markus Neteler wrote:
> I've never noticed it, because man/Makefile silently skips building
> the manpages if Perl isn't present (I don't have it on Windows).That's right but "tar" complains (read: warns) about the missing man
stuff later. Perhaps it has to be conditionalized upon perl presence
as well.
It's better to test what's actually required (i.e. the presence of the
dist.<arch>/man directory).
> Maybe we should use the Python version from 7.0? Many users will want
> Python anyhow, whereas Perl is only used for g.html2man.Sounds good, we would get rid of a dependency.
g.html2man.py shouldn't have any actual dependencies of its own.
However, I did have to clean up quite a few files in 7.0 to get the
parser to accept them (it's an actual HTML parser, and not
particularly fault-tolerant; the Perl version is just regexp
search/replace, so it might fail but it won't complain).
> OTOH, how many Windows users will want nroff manpages?
Likely 0.001%. It was more for a potential breakage of the packaging
process.
Then it's probably beter to just modify the packager.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2010/1/19 Hamish <hamish_b@yahoo.com>:
Glynn wrote:
Maybe we should use the Python version from 7.0? Many users
will want Python anyhow, whereas Perl is only used for
g.html2man.At this point, my vote, AFA 6.4.0 goes, is to follow the path of
least change. Which is to keep the existing perl script.
OK, anyway I would vote to replace Perl script in 6.5.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
On Tue, Jan 19, 2010 at 12:29 PM, Martin Landa <landa.martin@gmail.com> wrote:
2010/1/19 Hamish <hamish_b@yahoo.com>:
Glynn wrote:
Maybe we should use the Python version from 7.0? Many users
will want Python anyhow, whereas Perl is only used for
g.html2man.At this point, my vote, AFA 6.4.0 goes, is to follow the path of
least change. Which is to keep the existing perl script.OK, anyway I would vote to replace Perl script in 6.5.
Agreed - we may then backport to 6.4.1 if possible and stable.
Markus
Glynn wrote:
Maybe we should use the Python version from 7.0? Many users
will want Python anyhow, whereas Perl is only used for
g.html2man.
Hamish:
At this point, my vote, AFA 6.4.0 goes, is to follow the
path of least change. Which is to keep the existing perl
script.
Martin:
OK, anyway I would vote to replace Perl script in 6.5.
Markus:
Agreed - we may then backport to 6.4.1 if possible and stable.
actually now that I think about it, this is much more of a
shift in policy and I'm not sure if we should think about it
for 6.5 either.
Remember that currently python is not a mandatory build dep for
GRASS 6.x.
Also AFAIK python does not come preinstalled on e.g. debian as
a base package, but perl does.
So we are making python a mandatory build dep for ... getting
man(1) pages working on MS Windows ?? seems very dis-
proportionate to me.
Hamish
On Tue, Jan 19, 2010 at 8:51 PM, Hamish <hamish_b@yahoo.com> wrote:
Glynn wrote:
Maybe we should use the Python version from 7.0? Many users
will want Python anyhow, whereas Perl is only used for
g.html2man.
...
Martin:
OK, anyway I would vote to replace Perl script in 6.5.
...
actually now that I think about it, this is much more of a
shift in policy and I'm not sure if we should think about it
for 6.5 either.Remember that currently python is not a mandatory build dep for
GRASS 6.x.
Good point.
Also AFAIK python does not come preinstalled on e.g. debian as
a base package, but perl does.
Well, but Debian is not the gold standard (sorry). On other systems
it does.
So we are making python a mandatory build dep for ... getting
man(1) pages working on MS Windows ?? seems very dis-
proportionate to me.
I darkly remember a new GUI 
But I agree that Python is not a mandatory build dep for GRASS 6.x.
Markus
Hamish wrote:
>>>> Maybe we should use the Python version from 7.0? Many users
>>>> will want Python anyhow, whereas Perl is only used for
>>>> g.html2man.
Hamish:
>>> At this point, my vote, AFA 6.4.0 goes, is to follow the
>>> path of least change. Which is to keep the existing perl
>>> script.
Martin:
>> OK, anyway I would vote to replace Perl script in 6.5.
Markus:
> Agreed - we may then backport to 6.4.1 if possible and stable.actually now that I think about it, this is much more of a
shift in policy and I'm not sure if we should think about it
for 6.5 either.Remember that currently python is not a mandatory build dep for
GRASS 6.x.Also AFAIK python does not come preinstalled on e.g. debian as
a base package, but perl does.So we are making python a mandatory build dep for ... getting
man(1) pages working on MS Windows ?? seems very dis-
proportionate to me.
Why is making a Python a mandatory build dependency worse than making
Perl a mandatory build dependency? At least Python is useful for other
things, while Perl is *only* used for g.html2man.
As for the merits of the two versions of g.html2man: the Python
version can handle tables, although the Perl version has the advantage
that it can't fail (it may produce garbage, but AFAICT it will produce
*something* so long as the input file exists).
IMHO, the main reason to stick with the Perl version isn't down to
which language to make a required dependency, but the effort required
to clean up the 6.x manpages.
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, Jan 20, 2010 at 6:15 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
...
IMHO, the main reason to stick with the Perl version isn't down to
which language to make a required dependency, but the effort required
to clean up the 6.x manpages.
If the Python version would be backported to 6.5, I could walk through the
HTML pages, fix them and backport the HTML bugfixes to 6.4. They should
be done in any case...
Markus
Markus Neteler wrote:
> IMHO, the main reason to stick with the Perl version isn't down to
> which language to make a required dependency, but the effort required
> to clean up the 6.x manpages.If the Python version would be backported to 6.5, I could walk through the
HTML pages, fix them and backport the HTML bugfixes to 6.4. They should
be done in any case...
Back-porting is just a matter of copying g.html2man.py from 7.0 and
changing HTML2MAN in man/Makefile (remove the "sh").
Trying this, I get errors in 66 files, while 416 build without error.
If parsing fails, g.html2man.py will display the line number and the
line, but won't describe the error (most of them are due to using
block-level elements as if they were inline; using blocks inside
<dt>...</dt> is a common flaw).
There is some useful information on validation at:
http://grass.osgeo.org/wiki/Updating_GRASS_Documentation#A_brief_guide_to_valid_HTML
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, Jan 20, 2010 at 12:16 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
...
Back-porting is just a matter of copying g.html2man.py from 7.0 and
changing HTML2MAN in man/Makefile (remove the "sh").
[and add the .py extension of course]
Trying this, I get errors in 66 files, while 416 build without error.
If parsing fails, g.html2man.py will display the line number and the
line, but won't describe the error (most of them are due to using
block-level elements as if they were inline; using blocks inside
<dt>...</dt> is a common flaw).
I have reduced it to these errors here:
htmlmapdriver.html:63
wxGUI.html:154
wxGUI.Vector_Digitizing_Tool.html:210
Those are tricky <dd> issues (too tired now),
Markus
Markus wrote:
I have reduced it to these errors here:
htmlmapdriver.html:63
wxGUI.html:154
wxGUI.Vector_Digitizing_Tool.html:210
thanks,
Those are tricky <dd> issues (too tired now),
yeah, and https://trac.osgeo.org/grass/ticket/612
(r37877 never got backported (or foreported) btw; I'm not much
of a fan of the perl version but am not being a stick in the mud
about keeping it without having been here before...)
just one last repeat of the python vs. perl dep: you can expect
to find a usable perl on any linux distro >100mb.
It is much more mature than python so you don't have to worry
about installed version much (if at all), and [as far as linux
goes anyway, and I expect OSX too] you can be pretty confident
that it will already be installed and work regardless of distro
& setup. It will be many years before you can expect the same
stability from python (esp. with 3.0+ coming) so it is less to
maintain in the long term for a branch we don't want to touch.
I will concede that for 6.5+ the default GUI is wxpy, so it is
not unreasonable to expect to find python there.
regards,
Hamish
On Wed, Jan 20, 2010 at 5:30 PM, Hamish <hamish_b@yahoo.com> wrote:
Markus wrote:
I have reduced it to these errors here:
htmlmapdriver.html:63
wxGUI.html:154
wxGUI.Vector_Digitizing_Tool.html:210
...
yeah, and https://trac.osgeo.org/grass/ticket/612
...
just one last repeat of the python vs. perl dep:
Simple suggestion for 6.4: Since the backport of the Python version is
trivial, why not have both converters in Perl and Python?
Use Perl as default and, if missing, try the Python version.
?
Markus
Markus Neteler wrote:
>> I have reduced it to these errors here:
>> htmlmapdriver.html:63
>> wxGUI.html:154
>> wxGUI.Vector_Digitizing_Tool.html:210
...
> yeah, and https://trac.osgeo.org/grass/ticket/612
...
> just one last repeat of the python vs. perl dep:Simple suggestion for 6.4: Since the backport of the Python version is
trivial, why not have both converters in Perl and Python?
Use Perl as default and, if missing, try the Python version.
I'd suggest the other way around. The Python version can handle
tables, the Perl version can't. That's why I wrote the Python version
in the first place.
--
Glynn Clements <glynn@gclements.plus.com>
Markus:
why not have both converters in Perl and Python?
seems like too much double handling to me. just pick whichever one and go
with it. sorting the rest out as needed is probably less work than trying
to get the two to work in parallel.
Hamish