Hi,
I have backported recent fixes/license updates to the
new release branch except for
- basename
- r.out.tiff
- new Vect_*() changes
Just tell me if I should or not. If course I don't mind
if you backport directly (which is yet easy).
Markus
Hmmm, I am getting an error trying to compile the vector lib
on MingW now:
cd lib/vector/
make
make -C rtree || echo /src/grass6/lib/vector/rtree >> /src/grass6/error.log
make[1]: Entering directory `/src/grass6/lib/vector/rtree'
make[1]: *** No rule to make target
`/src/grass6/dist.i686-pc-mingw32/include/grass/rtree/card.h', needed by
`lib'. Stop.
make[1]: Leaving directory `/src/grass6/lib/vector/rtree'
make -C dglib || echo /src/grass6/lib/vector/dglib >> /src/grass6/error.log
make[1]: Entering directory `/src/grass6/lib/vector/dglib'
make[1]: Leaving directory `/src/grass6/lib/vector/dglib'
make -C diglib || echo /src/grass6/lib/vector/diglib >>
/src/grass6/error.log
make[1]: Entering directory `/src/grass6/lib/vector/diglib'
make OBJ.i686-pc-mingw32
make[2]: Entering directory `/src/grass6/lib/vector/diglib'
make[2]: `OBJ.i686-pc-mingw32' is up to date.
make[2]: Leaving directory `/src/grass6/lib/vector/diglib'
gcc -I/src/grass6/dist.i686-pc-mingw32/include -I/usr/include -g -O2
-I/usr/include -DPACKAGE=\""grasslibs"\" -I/usr/include
-DPACKAGE=\""grasslibs"\" -I/src/grass6/dist.i686-pc-mingw32/include -o
OBJ.i686-pc-mingw32/allocation.o -c allocation.c
In file included from
C:/msys/1.0/src/grass6/dist.i686-pc-mingw32/include/grass/vect/digit.h:3,
from
C:/msys/1.0/src/grass6/dist.i686-pc-mingw32/include/grass/Vect.h:4,
from allocation.c:22:
C:/msys/1.0/src/grass6/dist.i686-pc-mingw32/include/grass/vect/dig_structs.h:18:25:
grass/rtree.h: No such file or directory
make[1]: *** [OBJ.i686-pc-mingw32/allocation.o] Error 1
make[1]: Leaving directory `/src/grass6/lib/vector/diglib'
make -C Vlib || echo /src/grass6/lib/vector/Vlib >> /src/grass6/error.log
make[1]: Entering directory `/src/grass6/lib/vector/Vlib'
make OBJ.i686-pc-mingw32
make[2]: Entering directory `/src/grass6/lib/vector/Vlib'
make[2]: `OBJ.i686-pc-mingw32' is up to date.
make[2]: Leaving directory `/src/grass6/lib/vector/Vlib'
gcc -I/src/grass6/dist.i686-pc-mingw32/include -I/usr/include -g -O2
-I/usr/include -DPACKAGE=\""grasslibs"\" -I/usr/include
-DPACKAGE=\""grasslibs"\" -DPACKAGE=\""grasslibs"\"
-I/src/grass6/dist.i686-pc-mingw32/include -o OBJ.i686-pc-mingw32/area.o
-c area.c
In file included from
C:/msys/1.0/src/grass6/dist.i686-pc-mingw32/include/grass/vect/digit.h:3,
from
C:/msys/1.0/src/grass6/dist.i686-pc-mingw32/include/grass/Vect.h:4,
from area.c:20:
C:/msys/1.0/src/grass6/dist.i686-pc-mingw32/include/grass/vect/dig_structs.h:18:25:
grass/rtree.h: No such file or directory
make[1]: *** [OBJ.i686-pc-mingw32/area.o] Error 1
make[1]: Leaving directory `/src/grass6/lib/vector/Vlib'
make -C transform || echo /src/grass6/lib/vector/transform >>
/src/grass6/error.log
make[1]: Entering directory `/src/grass6/lib/vector/transform'
make[1]: Leaving directory `/src/grass6/lib/vector/transform'
My sources are a few hours old. When did you commit these changes?
Could they be the cause of my troubles?
Cheers,
Benjamin
Markus Neteler wrote:
Hi,
I have backported recent fixes/license updates to the
new release branch except for- basename
- r.out.tiff
- new Vect_*() changesJust tell me if I should or not. If course I don't mind
if you backport directly (which is yet easy).Markus
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
Benjamin Ducke wrote:
Hmmm, I am getting an error trying to compile the vector lib
on MingW now:cd lib/vector/
makemake -C rtree || echo /src/grass6/lib/vector/rtree >> /src/grass6/error.log
make[1]: Entering directory `/src/grass6/lib/vector/rtree'
make[1]: *** No rule to make target
`/src/grass6/dist.i686-pc-mingw32/include/grass/rtree/card.h', needed by
`lib'. Stop.
The rule should be there in the Makefile:
RTLINC = $(ARCH_INCDIR)/rtree
...
$(RTLINC)/%.h: %.h | $(RTLINC)
$(INSTALL_DATA) $< $@
My sources are a few hours old. When did you commit these changes?
Could they be the cause of my troubles?
The last update to lib/vector/rtree was:
RCS file: /grassrepository/grass6/lib/vector/rtree/Makefile,v
Working file: Makefile
head: 1.10
branch:
locks: strict
access list:
keyword substitution: kv
total revisions: 10; selected revisions: 1
description:
----------------------------
revision 1.10
date: 2007/10/19 13:45:53; author: glynn; state: Exp; lines: +12 -14
Only install grass<ver>.bat on Windows (MinGW)
Fix Windows build problems with d.frame, v.voronoi
Fix (?) parallel build problems with lib/vector/rtree and lib/gpde
Avoid trying to "install" lib/gis/colors/CVS directory
The there are no differences between the trunk, 6.3 release branch,
and 6.3-RC1 for lib/vector/rtree.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
The rule should be there in the Makefile:
RTLINC = $(ARCH_INCDIR)/rtree
...
$(RTLINC)/%.h: %.h | $(RTLINC)
$(INSTALL_DATA) $< $@
As indeed it is, but in my CVS copy (fresh checkout from 30 mins ago,
deleted the old copy completely),
the make rule for 'HEADERS' is in the wrong place!
It is on a line preceeding the 'lib' target, which means that
the latter can't find it.
It needs to be moved down a few lines in the Makefile, so that
it appears after the 'lib' target.
Also, as it stands the Makefile fails to copy rtree.h into
grass6/dist.$ARCH/include/grass/
The same goes for card.h, index.h and split_q.h which should
end up in grass6/dist.$ARCH/include/grass/rtree/ but don't.
I ended up copying these manually.
In addition, a "make clean" in the lib/vector/ top level
directory results in a whole bunch of error messages
of the form:
rm -rf OBJ.i686-pc-mingw32
rm -f *.tmp.html
if [ "" != "" ] ; then \
for dir in ; do \
make -C $dir clean ; \
done ; \
fi
/bin/sh: -c: line 1: syntax error near unexpected token `;'
/bin/sh: -c: line 1: `if [ "" != "" ] ; then for dir in ; do make -C
$dir clean ; done ; fi'
make: [clean] Error 2 (ignored)
Could someone with a better understanding of the GRASS
Makefile syntax please look into these issues?
Thanks,
Benjamin
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
Benjamin Ducke wrote:
> The rule should be there in the Makefile:
>
> RTLINC = $(ARCH_INCDIR)/rtree
> ...
> $(RTLINC)/%.h: %.h | $(RTLINC)
> $(INSTALL_DATA) $< $@
>As indeed it is, but in my CVS copy (fresh checkout from 30 mins ago,
deleted the old copy completely),
the make rule for 'HEADERS' is in the wrong place!It is on a line preceeding the 'lib' target, which means that
the latter can't find it.It needs to be moved down a few lines in the Makefile, so that
it appears after the 'lib' target.
The positioning doesn't matter in this case. Where a variable's value
is used as a dependency, the variable must be defined prior to the
reference, but that's the case here.
However, I see what's wrong with it; it's another case where adding
dependencies to a phony target from the *.make files doesn't behave as
expected, as described in:
http://grass.itc.it/pipermail/grass-dev/2007-October/033559.html
Essentially, both $(HEADERS) and the actual library are dependencies
of "lib", and it's unspecified which order they're built in. On my
system, $(HEADERS) get built first (otherwise I'd have noticed it by
now); on yours, the library gets built first, and fails because the
headers haven't been installed.
Using a recursive make should fix it:
--- lib/vector/rtree/Makefile 19 Oct 2007 13:45:53 -0000 1.10
+++ lib/vector/rtree/Makefile 26 Oct 2007 09:28:19 -0000
@@ -15,9 +15,8 @@
HEADERS := $(RTLINC)/card.h $(RTLINC)/index.h $(RTLINC)/split_q.h \
$(ARCH_INCDIR)/rtree.h
-default: lib
-
-lib: $(HEADERS)
+default: $(HEADERS)
+ $(MAKE) lib
$(RTLINC):
$(MKDIR) $@
In addition, a "make clean" in the lib/vector/ top level
directory results in a whole bunch of error messages
of the form:rm -rf OBJ.i686-pc-mingw32
rm -f *.tmp.html
if [ "" != "" ] ; then \
for dir in ; do \
make -C $dir clean ; \
done ; \
fi
/bin/sh: -c: line 1: syntax error near unexpected token `;'
/bin/sh: -c: line 1: `if [ "" != "" ] ; then for dir in ; do make -C
$dir clean ; done ; fi'
make: [clean] Error 2 (ignored)
I'm not entirely sure what the error is here; the test should be
false, so it shouldn't be interpreting the body of the "if".
As it says, the error is ignored. It would be nice to clean that up,
but it's not critical.
What happens if you enter the following directly into the shell?
if [ "" != "" ] ; then for dir in ; do make -C $dir clean ; done ; fi
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
Using a recursive make should fix it:
--- lib/vector/rtree/Makefile 19 Oct 2007 13:45:53 -0000 1.10
+++ lib/vector/rtree/Makefile 26 Oct 2007 09:28:19 -0000
@@ -15,9 +15,8 @@
HEADERS := $(RTLINC)/card.h $(RTLINC)/index.h $(RTLINC)/split_q.h \
$(ARCH_INCDIR)/rtree.h-default: lib
-
-lib: $(HEADERS)
+default: $(HEADERS)
+ $(MAKE) lib$(RTLINC):
$(MKDIR) $@
Sorry, but this still results in:
make: *** No rule to make target
`/src/grass6/dist.i686-pc-mingw32/include/grass/rtree/card.h', needed by
`default'. Stop.
(the only difference being that make now bails out before compiling
any objects in rtree).
What happens if you enter the following directly into the shell?
if [ "" != "" ] ; then for dir in ; do make -C $dir clean ; done ; fi
sh: syntax error near unexpected token `;'
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
Benjamin Ducke wrote on 10/26/2007 12:29 PM:
What happens if you enter the following directly into the shell?
if [ "" != "" ] ; then for dir in ; do make -C $dir clean ; done ; fi
sh: syntax error near unexpected token `;'
In that rule the list is empty:
... for dir in WHAT?;...
Isn't that the problem?
Or no ; after/before "done"?
Markus
Markus Neteler wrote on 10/25/2007 06:15 PM:
Hi,
I have backported recent fixes/license updates to the
new release branch except for- basename
- r.out.tiff
the two above are now backported.
Markus
- new Vect_*() changes
Just tell me if I should or not. If course I don't mind
if you backport directly (which is yet easy).Markus
True. I guess there should be a check for an unset var to not run
this loop. However, I don't know what that var is.
Apparently there is no harm in running that loop with an empty list
except for cosmetics (ugly error message). But I just can't be sure
until I know about the WHAT.
Benjamin
Markus Neteler wrote:
Benjamin Ducke wrote on 10/26/2007 12:29 PM:
What happens if you enter the following directly into the shell?
if [ "" != "" ] ; then for dir in ; do make -C $dir clean ; done ; fi
sh: syntax error near unexpected token `;'
In that rule the list is empty:
... for dir in WHAT?;...
Isn't that the problem?
Or no ; after/before "done"?Markus
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
Benjamin Ducke wrote:
> Using a recursive make should fix it:
>
> --- lib/vector/rtree/Makefile 19 Oct 2007 13:45:53 -0000 1.10
> +++ lib/vector/rtree/Makefile 26 Oct 2007 09:28:19 -0000
> @@ -15,9 +15,8 @@
> HEADERS := $(RTLINC)/card.h $(RTLINC)/index.h $(RTLINC)/split_q.h \
> $(ARCH_INCDIR)/rtree.h
>
> -default: lib
> -
> -lib: $(HEADERS)
> +default: $(HEADERS)
> + $(MAKE) lib
>
> $(RTLINC):
> $(MKDIR) $@
>Sorry, but this still results in:
make: *** No rule to make target
`/src/grass6/dist.i686-pc-mingw32/include/grass/rtree/card.h', needed by
`default'. Stop.(the only difference being that make now bails out before compiling
any objects in rtree).
Okay, that's a different issue. I have no idea what, though; the
required rule is quite definitely there.
> What happens if you enter the following directly into the shell?
>
> if [ "" != "" ] ; then for dir in ; do make -C $dir clean ; done ; fi
>sh: syntax error near unexpected token `;'
I don't think that there's much can be done there; you'll just have to
live with the noise.
--
Glynn Clements <glynn@gclements.plus.com>
Markus Neteler wrote:
>> What happens if you enter the following directly into the shell?
>>
>> if [ "" != "" ] ; then for dir in ; do make -C $dir clean ; done ; fi
>>
>>
>
> sh: syntax error near unexpected token `;'
>
>In that rule the list is empty:
... for dir in WHAT?;...
Isn't that the problem?
Yes. But that statement is conditionalised upon:
if [ "" != "" ] ; then ...
The empty string *is* equal to itself, so the test should fail, and
there's no need to execute the command.
Note that the error is ignored, so it doesn't have any effect other
than adding some noise.
--
Glynn Clements <glynn@gclements.plus.com>
Benjamin Ducke wrote:
True. I guess there should be a check for an unset var to not run
this loop. However, I don't know what that var is.
There is a check, hence the 'if [ "" != "" ] ...' part. But the shell
seems to be complaining about being unable to parse the command even
though it isn't going to execute it.
The command in question is the last one for the "clean" target in
Rules.make:
clean:
-rm -rf $(OBJDIR) $(EXTRA_CLEAN_DIRS)
-rm -f $(EXTRA_CLEAN_FILES) *.tmp.html
-if [ "$(CLEAN_SUBDIRS)" != "" ] ; then \
for dir in $(CLEAN_SUBDIRS) ; do \
$(MAKE) -C $$dir clean ; \
done ; \
fi
--
Glynn Clements <glynn@gclements.plus.com>
Glynn wrote:
There is a check, hence the 'if [ "" != "" ] ...' part. But the shell
seems to be complaining about being unable to parse the command even
though it isn't going to execute it.The command in question is the last one for the "clean" target in
Rules.make:clean:
-rm -rf $(OBJDIR) $(EXTRA_CLEAN_DIRS)
-rm -f $(EXTRA_CLEAN_FILES) *.tmp.html
-if [ "$(CLEAN_SUBDIRS)" != "" ] ; then \
for dir in $(CLEAN_SUBDIRS) ; do \
$(MAKE) -C $$dir clean ; \
done ; \
fi
how about
- -if [ "$(CLEAN_SUBDIRS)" != "" ] ; then \
+ -if [ -n "$(CLEAN_SUBDIRS)" ] ; then \
What OS & make version are you running Benjamin?
Hamish
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
I am compiling using MinGW 5.1.3 (GCC 3.4.2 and Make 3.79)
on Windows 2000 in an MSYS 1.0.11 shell.
I know that there are some problems with the GRASS
Makefiles and Make < 3.81.
For example, it fails parsing lib/form/Makefile because
it cannot interpret the "¦" correctly.
Make 3.81 can handle the pipe correctly. However, it fails
miserably with plenty of error messages about not being
able to find some path, mostly like this:
process_begin: CreateProcess(NULL, /bin/install -c -m 644
html_library_grass.tcl
/src/grass6/dist.i686-pc-mingw32/etc/form/html_library.tcl, ...) failed.
make (e=3): System cannot find the path specified.
make: *** [/src/grass6/dist.i686-pc-mingw32/etc/form/html_library.tcl]
Error 3
There are other, equally idiotic error messages.
The worst thing is that I can't kill it with CTRL+C.
It spans multiple instances and keeps coming back up.
What a nuisance.
So, unless someone can tell me what's wrong with
MinGW 3.81 and GRASS 6.3, I am stuck with Make 3.79.
Anyhow, the untidy error output discussed below persists
also with make 3.81.
Benjamin
Hamish wrote:
Glynn wrote:
There is a check, hence the 'if [ "" != "" ] ...' part. But the shell
seems to be complaining about being unable to parse the command even
though it isn't going to execute it.The command in question is the last one for the "clean" target in
Rules.make:clean:
-rm -rf $(OBJDIR) $(EXTRA_CLEAN_DIRS)
-rm -f $(EXTRA_CLEAN_FILES) *.tmp.html
-if [ "$(CLEAN_SUBDIRS)" != "" ] ; then \
for dir in $(CLEAN_SUBDIRS) ; do \
$(MAKE) -C $$dir clean ; \
done ; \
fihow about
- -if [ "$(CLEAN_SUBDIRS)" != "" ] ; then \
+ -if [ -n "$(CLEAN_SUBDIRS)" ] ; then \What OS & make version are you running Benjamin?
Hamish
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
Benjamin Ducke wrote:
I am compiling using MinGW 5.1.3 (GCC 3.4.2 and Make 3.79)
on Windows 2000 in an MSYS 1.0.11 shell.
I know that there are some problems with the GRASS
Makefiles and Make < 3.81.For example, it fails parsing lib/form/Makefile because
it cannot interpret the "¦" correctly.
[It's actually a "|" (bar) rather than a "¦" (brokenbar).]
Make 3.81 can handle the pipe correctly. However, it fails
miserably with plenty of error messages about not being
able to find some path, mostly like this:process_begin: CreateProcess(NULL, /bin/install -c -m 644
html_library_grass.tcl
/src/grass6/dist.i686-pc-mingw32/etc/form/html_library.tcl, ...) failed.
make (e=3): System cannot find the path specified.
make: *** [/src/grass6/dist.i686-pc-mingw32/etc/form/html_library.tcl]
Error 3
Does the etc/form directory actually exist? lib/form/Makefile relies
upon an order-only dependency (which uses the bar) to create that
directory:
$(FORMDIR):
if [ ! -d $@ ]; then $(MKDIR) $@; fi
$(HTMLLIB): html_library_grass.tcl | $(FORMDIR)
$(INSTALL_DATA) $< $@
Does the mkdir command ever get executed?
There are other, equally idiotic error messages.
Is there any common factor?
The one related to lib/form appears to be yet another issue with
order-only dependencies. IOW, neither of MinGW's make ports support
them.
Unfortunately, it's starting to look as if the only solution which
will work with both parallel make and any MinGW make port is to
unconditionally create the output directory every time.
The worst thing is that I can't kill it with CTRL+C.
It spans multiple instances and keeps coming back up.
What a nuisance.
I don't think there's a solution to that; Windows doesn't have process
groups.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
Unfortunately, it's starting to look as if the only solution which
will work with both parallel make and any MinGW make port is to
unconditionally create the output directory every time.
I have conditionalised all of the order-only prerequisites upon the
variable BROKEN_MAKE. This will be set by default if make is not 3.81,
but can be set explicitly with e.g. "make BROKEN_MAKE=1 ...".
The downside that, when this variable is set, several modules (e.g.
r.terraflow) will be re-compiled from scratch if you re-run make, as
the OBJ.<arch> directory is now an unconditional prerequisite, and
will normally be newer than the object files which it contains.
--
Glynn Clements <glynn@gclements.plus.com>