[GRASS-user] Building wxgrass vdigit

GRASS GRASS user
1

Hi

I am trying out the new wxpython gui from trunk for the first time and I am
running into some trouble with building vdigit.

My system is an i586 32 bit Ubuntu Gutsy (7.10) box and I have built the 6.3
RC3 branch from source. I have followed the instructions in the wxpython
README and I can launch the gui, but building vdigit fails. Please see
below:

GRASS 6.3.0RC3 (msunduzi_lo31):~ > cd $GISBASE/etc/wx/vdigit
GRASS 6.3.0RC3 (msunduzi_lo31):/usr/local/grass-6.3.0RC3/etc/wx/vdigit > ls
-l
total 76
-rw-r--r-- 1 craig craig 2583 2008-01-28 12:14 cats.cpp
-rw-r--r-- 1 craig craig 677 2008-01-28 12:14 digit.cpp
-rw-r--r-- 1 craig craig 1187 2008-01-28 12:14 digit.h
-rw-r--r-- 1 craig craig 325 2008-01-28 12:14 digit.i
-rw-r--r-- 1 craig craig 685 2008-01-28 12:14 dig_types.i
-rw-r--r-- 1 craig craig 26031 2008-01-28 12:14 driver.cpp
-rw-r--r-- 1 craig craig 4032 2008-01-28 12:14 driver.h
-rw-r--r-- 1 craig craig 307 2008-01-28 12:14 driver.i
-rw-r--r-- 1 craig craig 9779 2008-01-28 12:14 line.cpp
-rw-r--r-- 1 craig craig 1368 2008-01-28 12:14 Makefile.in
-rw-r--r-- 1 craig craig 2229 2008-01-28 12:14 vertex.cpp
GRASS 6.3.0RC3 (msunduzi_lo31):/usr/local/grass-6.3.0RC3/etc/wx/vdigit >
make
make: *** No targets specified and no makefile found. Stop.
GRASS 6.3.0RC3 (msunduzi_lo31):/usr/local/grass-6.3.0RC3/etc/wx/vdigit >
make ./Makefile.in
make: Nothing to be done for `Makefile.in'.

Am I correct in just trying to build vdigit or do I need to rebuild all of
GRASS?

Regards

Craig

--
View this message in context: http://www.nabble.com/Building-wxgrass-vdigit-tp15134401p15134401.html
Sent from the Grass - Users mailing list archive at Nabble.com.

2

Hi Craig,

2008/1/28, Craig Leat <Craig@pid.co.za>:

I am trying out the new wxpython gui from trunk for the first time and I am
running into some trouble with building vdigit.

My system is an i586 32 bit Ubuntu Gutsy (7.10) box and I have built the 6.3
RC3 branch from source. I have followed the instructions in the wxpython
README and I can launch the gui, but building vdigit fails. Please see
below:

GRASS 6.3.0RC3 (msunduzi_lo31):~ > cd $GISBASE/etc/wx/vdigit
GRASS 6.3.0RC3 (msunduzi_lo31):/usr/local/grass-6.3.0RC3/etc/wx/vdigit > ls
-l
total 76
-rw-r--r-- 1 craig craig 2583 2008-01-28 12:14 cats.cpp
-rw-r--r-- 1 craig craig 677 2008-01-28 12:14 digit.cpp
-rw-r--r-- 1 craig craig 1187 2008-01-28 12:14 digit.h
-rw-r--r-- 1 craig craig 325 2008-01-28 12:14 digit.i
-rw-r--r-- 1 craig craig 685 2008-01-28 12:14 dig_types.i
-rw-r--r-- 1 craig craig 26031 2008-01-28 12:14 driver.cpp
-rw-r--r-- 1 craig craig 4032 2008-01-28 12:14 driver.h
-rw-r--r-- 1 craig craig 307 2008-01-28 12:14 driver.i
-rw-r--r-- 1 craig craig 9779 2008-01-28 12:14 line.cpp
-rw-r--r-- 1 craig craig 1368 2008-01-28 12:14 Makefile.in
-rw-r--r-- 1 craig craig 2229 2008-01-28 12:14 vertex.cpp
GRASS 6.3.0RC3 (msunduzi_lo31):/usr/local/grass-6.3.0RC3/etc/wx/vdigit >
make
make: *** No targets specified and no makefile found. Stop.
GRASS 6.3.0RC3 (msunduzi_lo31):/usr/local/grass-6.3.0RC3/etc/wx/vdigit >
make ./Makefile.in
make: Nothing to be done for `Makefile.in'.

Am I correct in just trying to build vdigit or do I need to rebuild all of
GRASS?

run ./configure to create Makefile (based on Makefile.in)

Ragards, Martin

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

3

Martin Landa wrote:

Hi Craig,

2008/1/28, Craig Leat <Craig@pid.co.za>:
  

I am trying out the new wxpython gui from trunk for the first time and I am
running into some trouble with building vdigit.

My system is an i586 32 bit Ubuntu Gutsy (7.10) box and I have built the 6.3
RC3 branch from source. I have followed the instructions in the wxpython
README and I can launch the gui, but building vdigit fails. Please see
below:

GRASS 6.3.0RC3 (msunduzi_lo31):~ > cd $GISBASE/etc/wx/vdigit
GRASS 6.3.0RC3 (msunduzi_lo31):/usr/local/grass-6.3.0RC3/etc/wx/vdigit > ls
-l
total 76
-rw-r--r-- 1 craig craig 2583 2008-01-28 12:14 cats.cpp
-rw-r--r-- 1 craig craig 677 2008-01-28 12:14 digit.cpp
-rw-r--r-- 1 craig craig 1187 2008-01-28 12:14 digit.h
-rw-r--r-- 1 craig craig 325 2008-01-28 12:14 digit.i
-rw-r--r-- 1 craig craig 685 2008-01-28 12:14 dig_types.i
-rw-r--r-- 1 craig craig 26031 2008-01-28 12:14 driver.cpp
-rw-r--r-- 1 craig craig 4032 2008-01-28 12:14 driver.h
-rw-r--r-- 1 craig craig 307 2008-01-28 12:14 driver.i
-rw-r--r-- 1 craig craig 9779 2008-01-28 12:14 line.cpp
-rw-r--r-- 1 craig craig 1368 2008-01-28 12:14 Makefile.in
-rw-r--r-- 1 craig craig 2229 2008-01-28 12:14 vertex.cpp
GRASS 6.3.0RC3 (msunduzi_lo31):/usr/local/grass-6.3.0RC3/etc/wx/vdigit >
make
make: *** No targets specified and no makefile found. Stop.
GRASS 6.3.0RC3 (msunduzi_lo31):/usr/local/grass-6.3.0RC3/etc/wx/vdigit >
make ./Makefile.in
make: Nothing to be done for `Makefile.in'.

Am I correct in just trying to build vdigit or do I need to rebuild all of
GRASS?
    
run ./configure to create Makefile (based on Makefile.in)

Ragards, Martin

Hi Martin

Thanks for the pointer, but unfortunately I'm still having trouble. I first tried to add vdigit to an existing installation of RC3 without success. I then downloaded, configured and built trunk and the build completed without reporting any errors. I noticed that vdigit was not built along with the other modules, although a /grass-trunk/gui/wxpython/vdigit/Makefile was generated. This concerns me. Can anyone explain what's happening here?

Anyway, I then proceeded to try building vdigit after performing steps 1.1, 1.2 and 7.1 described in the wxpython README. The build failed with errors as below:

GRASS 6.3.svn (msunduzi_lo31):/usr/local/src/grass_trunk_28012008/gui/wxpython > cd $GISBASE/etc/wx/vdigit
GRASS 6.3.svn (msunduzi_lo31):/usr/local/grass-6.3SVN/etc/wx/vdigit > ls -l
total 80
-rw-r--r-- 1 craig craig 2583 2008-01-28 12:14 cats.cpp
-rw-r--r-- 1 craig craig 677 2008-01-28 12:14 digit.cpp
-rw-r--r-- 1 craig craig 1187 2008-01-28 12:14 digit.h
-rw-r--r-- 1 craig craig 325 2008-01-28 12:14 digit.i
-rw-r--r-- 1 craig craig 685 2008-01-28 12:14 dig_types.i
-rw-r--r-- 1 craig craig 26031 2008-01-28 12:14 driver.cpp
-rw-r--r-- 1 craig craig 4032 2008-01-28 12:14 driver.h
-rw-r--r-- 1 craig craig 307 2008-01-28 12:14 driver.i
-rw-r--r-- 1 craig craig 9779 2008-01-28 12:14 line.cpp
-rw-r--r-- 1 craig craig 1417 2008-01-30 09:32 Makefile
-rw-r--r-- 1 craig craig 1368 2008-01-28 12:14 Makefile.in
-rw-r--r-- 1 craig craig 2229 2008-01-28 12:14 vertex.cpp
GRASS 6.3.svn (msunduzi_lo31):/usr/local/grass-6.3SVN/etc/wx/vdigit > make
Makefile:27: warning: overriding commands for target `clean'
../../../include/Make/Rules.make:72: warning: ignoring old commands for target `clean'
mkdir -p /usr/local/src/grass_trunk_28012008/bin.i686-pc-linux-gnu
mkdir -p /usr/local/src/grass_trunk_28012008/dist.i686-pc-linux-gnu/include/grass
mkdir -p /usr/local/src/grass_trunk_28012008/dist.i686-pc-linux-gnu/lib
mkdir -p /usr/local/src/grass_trunk_28012008/dist.i686-pc-linux-gnu/bin
mkdir -p /usr/local/src/grass_trunk_28012008/dist.i686-pc-linux-gnu/etc
mkdir -p /usr/local/src/grass_trunk_28012008/dist.i686-pc-linux-gnu/driver
mkdir -p /usr/local/src/grass_trunk_28012008/dist.i686-pc-linux-gnu/driver/db
mkdir -p /usr/local/src/grass_trunk_28012008/dist.i686-pc-linux-gnu/fonts
cat ./digit.i > grass6_wxvdigit.i
cat ./dig_types.i >> grass6_wxvdigit.i
echo "/* auto-generate swig typedef file */" >> grass6_wxvdigit.i
cat ./driver.h >> grass6_wxvdigit.i
cat ./digit.h >> grass6_wxvdigit.i
swig -c++ -python -shadow grass6_wxvdigit.i
test -d OBJ.i686-pc-linux-gnu || mkdir -p OBJ.i686-pc-linux-gnu
c++ -c -c -fpic -I/usr/local/src/grass_trunk_28012008/dist.i686-pc-linux-gnu/include -I/usr/include/python2.5 `wx-config --cxxflags` grass6_wxvdigit_wrap.cxx -o OBJ.i686-pc-linux-gnu/grass6_wxvdigit_wrap.o
grass6_wxvdigit_wrap.cxx:2577:23: error: grass/gis.h: No such file or directory
grass6_wxvdigit_wrap.cxx:2578:27: error: grass/gisdefs.h: No such file or directory
grass6_wxvdigit_wrap.cxx:2579:24: error: grass/Vect.h: No such file or directory
grass6_wxvdigit_wrap.cxx:2580:36: error: grass/vect/dig_structs.h: No such file or directory
driver.h:70: error: \u2018BOUND_BOX\u2019 does not name a type
make: *** [OBJ.i686-pc-linux-gnu/grass6_wxvdigit_wrap.o] Error 1
GRASS 6.3.svn (msunduzi_lo31):/usr/local/grass-6.3SVN/etc/wx/vdigit >

I have puzzled over these error messages and it appears to me that the path to gis.h and friends has been set incorrectly. If this is the problem, do I fix this by editing the Makefile?

Regards

Craig

4

Craig Leat wrote:

>> I am trying out the new wxpython gui from trunk for the first time
>> and I am running into some trouble with building vdigit.

....

grass6_wxvdigit_wrap.cxx:2577:23: error: grass/gis.h: No such file or
directory

??

driver.h:70: error: \u2018BOUND_BOX\u2019 does not name a type
make: *** [OBJ.i686-pc-linux-gnu/grass6_wxvdigit_wrap.o] Error 1

"\u2018" -- unicode characters sneaking into what should be a flat
ASCII file?

Hamish

      ____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

5

Craig Leat wrote:

Thanks for the pointer, but unfortunately I'm still having trouble. I
first tried to add vdigit to an existing installation of RC3 without
success. I then downloaded, configured and built trunk and the build
completed without reporting any errors. I noticed that vdigit was not
built along with the other modules, although a
/grass-trunk/gui/wxpython/vdigit/Makefile was generated. This concerns
me. Can anyone explain what's happening here?

Anyway, I then proceeded to try building vdigit after performing steps
1.1, 1.2 and 7.1 described in the wxpython README. The build failed with
errors as below:

GRASS 6.3.svn
(msunduzi_lo31):/usr/local/src/grass_trunk_28012008/gui/wxpython > cd $GISBASE/etc/wx/vdigit

GRASS 6.3.svn (msunduzi_lo31):/usr/local/grass-6.3SVN/etc/wx/vdigit > make

grass6_wxvdigit_wrap.cxx:2577:23: error: grass/gis.h: No such file or directory

You need to do at least "make -C lib headers" before trying to build
anything else. Also, I suspect that it will expect to find the GRASS
libraries in the build tree (in dist.<arch>/lib), so you will probably
need at least "make -C lib".

Personally, I would recommend just building the whole of GRASS, by
running "make" from the top-level directory. Building individual
components requires some knowledge of which parts depend upon which
other parts, and acquiring this knowledge is likely to take somewhat
longer than just building everything.

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

6

Hi Glynn

Please see my comments below.

Glynn Clements wrote:

Craig Leat wrote:
  

I then downloaded, configured and built trunk and the build completed without reporting any errors. I noticed that vdigit was not built along with the other modules, although a /grass-trunk/gui/wxpython/vdigit/Makefile was generated. This concerns me. Can anyone explain what's happening here?
    
I have already tried building the whole of GRASS, as described above. No errors were reported, but vdigit wasn't built.

You need to do at least "make -C lib headers" before trying to build
anything else. Also, I suspect that it will expect to find the GRASS
libraries in the build tree (in dist.<arch>/lib), so you will probably
need at least "make -C lib".

Personally, I would recommend just building the whole of GRASS, by
running "make" from the top-level directory. Building individual
components requires some knowledge of which parts depend upon which
other parts, and acquiring this knowledge is likely to take somewhat
longer than just building everything.

I'll try building the whole of GRASS again, just in case I missed something and will report back. Thanks for the help so far.

Regards

Craig

7

Hamish wrote:

> >> I am trying out the new wxpython gui from trunk for the first time
> >> and I am running into some trouble with building vdigit.
....
> grass6_wxvdigit_wrap.cxx:2577:23: error: grass/gis.h: No such file or
> directory

??

> driver.h:70: error: \u2018BOUND_BOX\u2019 does not name a type
> make: *** [OBJ.i686-pc-linux-gnu/grass6_wxvdigit_wrap.o] Error 1

"\u2018" -- unicode characters sneaking into what should be a flat
ASCII file?

Those are just the quotes added by the compiler. Recent versions of
gcc have taken to using gratuitous non-ASCII punctuation in diagnostic
messages.

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

8

Glynn Clements <glynn@gclements.plus.com> writes:

[...]

>>> driver.h:70: error: \u2018BOUND_BOX\u2019 does not name a type
>>> make: *** [OBJ.i686-pc-linux-gnu/grass6_wxvdigit_wrap.o] Error 1

>> "\u2018" -- unicode characters sneaking into what should be a flat
>> ASCII file?

> Those are just the quotes added by the compiler. Recent versions of
> gcc have taken to using gratuitous non-ASCII punctuation in
> diagnostic messages.

  Is it due to a locale setting? It seems reasonable for GCC to
  put UTF-8 quotes when asked for such a locale.

  FWIW, I always suppress any localization by prepending
  `LC_ALL=C' to the `make' invocation, like:

$ LC_ALL=C nohup time make &

  (Otherwise one might get something like:

$ gcc none.c
gcc: none.c: Datei oder Verzeichnis nicht gefunden
gcc: no input files
$

  in the log; hardly a good thing to be included into a bug
  report.)

9

Ivan Shmakov wrote:

>>> driver.h:70: error: \u2018BOUND_BOX\u2019 does not name a type
>>> make: *** [OBJ.i686-pc-linux-gnu/grass6_wxvdigit_wrap.o] Error 1

>> "\u2018" -- unicode characters sneaking into what should be a flat
>> ASCII file?

> Those are just the quotes added by the compiler. Recent versions of
> gcc have taken to using gratuitous non-ASCII punctuation in
> diagnostic messages.

  Is it due to a locale setting? It seems reasonable for GCC to
  put UTF-8 quotes when asked for such a locale.

ASCII is a subset of UTF-8, so there's no problem with using the ASCII
quote characters in that situation.

It might be different if the locale was one which doesn't normally use
"..." for quotations. E.g. using «...» in a French locale or 「...」
in a Japanese locale might be reasonable. But the error message was
quite clearly in English.

If it was using non-ASCII characters in the C/POSIX locale, that would
be an unequivocal bug. As it is, it's merely a poor choice.

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

10

Glynn Clements <glynn@gclements.plus.com> writes:

>>>>> driver.h:70: error: \u2018BOUND_BOX\u2019 does not name a type
>>>>> make: *** [OBJ.i686-pc-linux-gnu/grass6_wxvdigit_wrap.o] Error 1

>>>> "\u2018" -- unicode characters sneaking into what should be a flat
>>>> ASCII file?

>>> Those are just the quotes added by the compiler. Recent versions of
>>> gcc have taken to using gratuitous non-ASCII punctuation in
>>> diagnostic messages.

>> Is it due to a locale setting? It seems reasonable for GCC to put
>> UTF-8 quotes when asked for such a locale.

> ASCII is a subset of UTF-8, so there's no problem with using the
> ASCII quote characters in that situation.

  That's the problem -- ASCII lacks single quote characters.

$ zcat /usr/share/i18n/charmaps/ANSI_X3.4-1968.gz
<code_set_name> ANSI_X3.4-1968
...

...
% alias ASCII
...
<U0027> /x27 APOSTROPHE
...
<U0060> /x60 GRAVE ACCENT
...
$

> It might be different if the locale was one which doesn't normally
> use "..." for quotations. E.g. using «...» in a French locale or
> 「...」 in a Japanese locale might be reasonable. But the error message
> was quite clearly in English.

> If it was using non-ASCII characters in the C/POSIX locale, that
> would be an unequivocal bug.

  In C/POSIX locale (as well as in the rest of the ASCII world),
  APOSTROPHE and GRAVE ACCENT are traditionally used to represent
  single quote characters. However, there's no need in such a
  behaviour when the character set has ``real'' single quote
  characters.

$ zcat /usr/share/i18n/charmaps/UTF-8.gz
<code_set_name> UTF-8
...

% alias ISO-10646/UTF-8
CHARMAP
...
<U2018> /xe2/x80/x98 LEFT SINGLE QUOTATION MARK
<U2019> /xe2/x80/x99 RIGHT SINGLE QUOTATION MARK
...
$

> As it is, it's merely a poor choice.

  I'd say that it's a behaviour consistent with that of other
  applications. I cannot imagine a case where this behaviour
  could be actually useful (other than inserting the program
  output into a UTF-8 printed document), but it's consistent.

PS. Is `utf8' a valid MIME charset name?

From: Glynn Clements <...>
Subject: Re: GCC vs. locale
Date: Sat, 2 Feb 2008 13:53:18 +0000
...
Message-ID: <18340.30158.625426.938920@...>
...
Mime-Version: 1.0
Content-Type: text/plain; charset=utf8
Content-Transfer-Encoding: quoted-printable

  My Gnus seemingly misrecognized it.

11

Ivan Shmakov wrote:

> ASCII is a subset of UTF-8, so there's no problem with using the
> ASCII quote characters in that situation.

  That's the problem -- ASCII lacks single quote characters.

It also lacks a decimal point character. But just as a full stop
(period) suffices as a decimal point, the apostrophe suffices as a
single quote character (e.g. C/C++, Bourne shell, etc).

It's not as if you actually *need* to use balanced quotes.

PS. Is `utf8' a valid MIME charset name?

iconv understands it as an alias for utf-8. I don't know whether MIME
specifies an exhaustive list of encodings.

FWIW, the fact that VM chose UTF-8 was news to me; historically, it
has used ISO-2022 for multi-lingual text.

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

12

Glynn Clements <glynn@gclements.plus.com> writes:

>>> ASCII is a subset of UTF-8, so there's no problem with using the
>>> ASCII quote characters in that situation.

>> That's the problem -- ASCII lacks single quote characters.

> It also lacks a decimal point character. But just as a full stop
> (period) suffices as a decimal point, the apostrophe suffices as a
> single quote character (e.g. C/C++, Bourne shell, etc).

  I'd let the programming languages alone, since otherwise I'd
  probably blame C compilers for not supporting comma as the
  decimal separator. Besides, the choice of particular ASCII
  characters for particular purposes is somewhat arbitrary within
  the scope.

> It's not as if you actually *need* to use balanced quotes.

  As I've said previously, I see this behaviour as consistent with
  the rest of the system. I see no necessity in it, yes.

>> PS. Is `utf8' a valid MIME charset name?

> iconv understands it as an alias for utf-8. I don't know whether MIME
> specifies an exhaustive list of encodings.

  MIME relies on IANA to define the convention on naming character
  sets. I've just checked it at [1], and it seems that there's no
  such MIME charset. Hence, the behaviour of Gnus is justified.

> FWIW, the fact that VM chose UTF-8 was news to me; historically, it
> has used ISO-2022 for multi-lingual text.

  It might be caused by the presense of the quote symbols.
  (Especially if they cannot be represented by ISO-2022; sorry, I
  know little about that character set to make a better guess.)

[1] http://www.iana.org/assignments/character-sets