I've recently stumbled across r.terraflow while performing google searches
and it sounds like the tool I'm looking for right now. When I tried to find
the command in the latest and greatest GRASS dist (cygwin 5.0.2), couldn't
find it. At least not in the binary dist.
Is it in there?
Jeff.
Jeff D. Hamann wrote:
I've recently stumbled across r.terraflow while performing google searches
and it sounds like the tool I'm looking for right now. When I tried to find
the command in the latest and greatest GRASS dist (cygwin 5.0.2), couldn't
find it. At least not in the binary dist.Is it in there?
It isn't in the 5.0.2 binary packages. The source code is in the 5.0.2
source packages and the CVS release branch, but the build system
doesn't have the necessary extensions.
Whereas the rest of GRASS is written in C, r.terraflow is written in
C++. This required some extensions to the build system; in turn, it
was decided (by me, primarily) that this was too controversial for
5.0.2 (i.e. the small risk of breaking everything outweighed the
benefits of one additional module).
If you want r.terraflow, you can either try building it manually (i.e.
hacking src/CMD/*) from the 5.0.2 source, or obtain the development
version from CVS (which has the necessary changes to configure etc;
you have to specify the --with-cxx switch in order for r.terraflow to
be built).
--
Glynn Clements <glynn.clements@virgin.net>
Glynn Clements wrote:
Jeff D. Hamann wrote:
The new version that compiles under gcc3.2 is at
http://www.cs.duke.edu/~laura/bin/
I did not have time to try it out and submit it,
so if you can test this latest version that would help. Also, let us
know if you
have any questions - it is still a work in progress.
Glynn is right that it belongs to the GRASS development version and
the previous version of r.terraflow is in src.contrib/DUKE
Helena
> I've recently stumbled across r.terraflow while performing google searches
> and it sounds like the tool I'm looking for right now. When I tried to find
> the command in the latest and greatest GRASS dist (cygwin 5.0.2), couldn't
> find it. At least not in the binary dist.
>
> Is it in there?It isn't in the 5.0.2 binary packages. The source code is in the 5.0.2
source packages and the CVS release branch, but the build system
doesn't have the necessary extensions.Whereas the rest of GRASS is written in C, r.terraflow is written in
C++. This required some extensions to the build system; in turn, it
was decided (by me, primarily) that this was too controversial for
5.0.2 (i.e. the small risk of breaking everything outweighed the
benefits of one additional module).If you want r.terraflow, you can either try building it manually (i.e.
hacking src/CMD/*) from the 5.0.2 source, or obtain the development
version from CVS (which has the necessary changes to configure etc;
you have to specify the --with-cxx switch in order for r.terraflow to
be built).--
Glynn Clements <glynn.clements@virgin.net>_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
It is easy to compile r.terraflow. Go in the r.terraflow directory
<grass-src-dir>/src.contrib/DUKE/r.terraflow
and run bin/gmake5
This should compile two executables, r.terraflow and r.terraflow.short and
place them in
<grass-src-dir>/dist.<platform>/etc/bin/cmd/
To see them from grass5 you copy them to (or make symbolic links)
<grass-dir>/bin/grass5/
Check out also http://www.cs.duke.edu/geo*/terraflow/
Let me know if you have troubles.
-Laura
On Mon, 9 Jun 2003, Helena wrote:
Glynn Clements wrote:
>
> Jeff D. Hamann wrote:
>The new version that compiles under gcc3.2 is at
http://www.cs.duke.edu/~laura/bin/I did not have time to try it out and submit it,
so if you can test this latest version that would help. Also, let us
know if you
have any questions - it is still a work in progress.
Glynn is right that it belongs to the GRASS development version and
the previous version of r.terraflow is in src.contrib/DUKEHelena
> > I've recently stumbled across r.terraflow while performing google searches
> > and it sounds like the tool I'm looking for right now. When I tried to find
> > the command in the latest and greatest GRASS dist (cygwin 5.0.2), couldn't
> > find it. At least not in the binary dist.
> >
> > Is it in there?
>
> It isn't in the 5.0.2 binary packages. The source code is in the 5.0.2
> source packages and the CVS release branch, but the build system
> doesn't have the necessary extensions.
>
> Whereas the rest of GRASS is written in C, r.terraflow is written in
> C++. This required some extensions to the build system; in turn, it
> was decided (by me, primarily) that this was too controversial for
> 5.0.2 (i.e. the small risk of breaking everything outweighed the
> benefits of one additional module).
>
> If you want r.terraflow, you can either try building it manually (i.e.
> hacking src/CMD/*) from the 5.0.2 source, or obtain the development
> version from CVS (which has the necessary changes to configure etc;
> you have to specify the --with-cxx switch in order for r.terraflow to
> be built).
>
> --
> Glynn Clements <glynn.clements@virgin.net>
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
Dear Helena and Laura,
Thank you for the great work on r.terraflow! It seems fast and well done. I
checked out version 1.5 and here is some feedback.
Ver. 1.5 compiled fine on my Mandrake 9.1 (GCC 3.2.2), with CVS GRASS, however
I had to do some manual editing. Specifying --with-cxx configure option was
not enough, I got "Compilation error in module: src.contrib/DUKE/r.terraflow
(ignored)".
The problem was with file paths in IOStream/lib/src/*.d files which are set
for a RedHat system. Once I changed redhat-specific paths to their mandrake
equivalents:
(a) /usr/lib/gcc-lib/i386-redhat-linux/3.2 =>
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2
(b) /usr/include/c++/3.2/i386-redhat-linux =>
/usr/include/c++/3.2.2/i586-mandrake-linux-gnu
everything compiled ok. I suppose this sort of thing will require more
C++-specific configure checks which probably won't be really needed until
5.1.
The rest of this is mostly about the HTML document page, with some general
questions/suggestions...
1. The "elev" argument is incorrectly documented as "elevin"
2. The HTML page seems confusing to me in the part explaining flooding and
sinks:
(a) "swatershed" output is described as "output sink-watershed raster", yet
what it really seems to hold is a map of subwatersheds. Using "sink" is
really confusing here, since it most commonly means a point from which there
is no outflow (and this is how sinks are described in the text just above --
as "areas that do not spill out"). Why not call it "watershed" and describe
as a map that holds small subwatersheds?
(b) BTW, what controls the size of those subwatersheds saved in the
"swatershed" map? (Something similat to "threshold" in r.watershed may be
nice...)
(c) "Flooding produces a sink-less terrain in which every cell has a
downslope flow path leading outside the terrain ..." -- Does this mean that
all internal no-outlet subbasins (like catchment of a no-outlet lake) are
filled in?
(d) I used a float DEM and my output flooded (I think it's clearer to call it
sinkless or depressionless) DEM is a CELL. Why not FCELL, for computational
and storage reasons?
I hope I don't come accross as nagging or unappreciative! You've done a great
work, I just thought I'd put in my 0.05c 
Thank you,
Aleksey
On Monday 09 June 2003 06:54 pm, Helena wrote:
The new version that compiles under gcc3.2 is at
http://www.cs.duke.edu/~laura/bin/I did not have time to try it out and submit it,
so if you can test this latest version that would help. Also, let us
know if you
have any questions - it is still a work in progress.
Glynn is right that it belongs to the GRASS development version and
the previous version of r.terraflow is in src.contrib/DUKEHelena
Dear Aleksey,
Thanks for your feedback. I asnwered some of your comments below. We'll
try to make the html page clearer.
I put a new tar-ball at
http://www.cs.duke.edu/~laura/bin/
-Laura
On Thu, 12 Jun 2003, Aleksey Naumov wrote:
Dear Helena and Laura,
Thank you for the great work on r.terraflow! It seems fast and well done. I
checked out version 1.5 and here is some feedback.Ver. 1.5 compiled fine on my Mandrake 9.1 (GCC 3.2.2), with CVS GRASS, however
I had to do some manual editing. Specifying --with-cxx configure option was
not enough, I got "Compilation error in module: src.contrib/DUKE/r.terraflow
(ignored)".
The problem was with file paths in IOStream/lib/src/*.d files which are set
for a RedHat system. Once I changed redhat-specific paths to their mandrake
equivalents:
(a) /usr/lib/gcc-lib/i386-redhat-linux/3.2 =>
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2
(b) /usr/include/c++/3.2/i386-redhat-linux =>
/usr/include/c++/3.2.2/i586-mandrake-linux-gnu
everything compiled ok. I suppose this sort of thing will require more
C++-specific configure checks which probably won't be really needed until
5.1.
the *.d files in IOSTREAM are generated automatically. my mistake
not to clean up before making the tar ball. Should work if you delete them
and try compiling again from scratch.
The rest of this is mostly about the HTML document page, with some general
questions/suggestions...1. The "elev" argument is incorrectly documented as "elevin"
fixed.
2. The HTML page seems confusing to me in the part explaining flooding and
sinks:
(a) "swatershed" output is described as "output sink-watershed raster", yet
what it really seems to hold is a map of subwatersheds. Using "sink" is
really confusing here, since it most commonly means a point from which there
is no outflow (and this is how sinks are described in the text just above --
as "areas that do not spill out"). Why not call it "watershed" and describe
as a map that holds small subwatersheds?(b) BTW, what controls the size of those subwatersheds saved in the
"swatershed" map? (Something similat to "threshold" in r.watershed may be
nice...)
In Terraflow the watershed of a sink represents the *entire* area that
flows into the sink. Basically each sink-watershed represents a bucket in
the ground that will fill with water when it rains (long enough). Each
sink-watershed is well-defined, and does not depend on the choice of a
threshold. Selecting all the sinks in the terrain and computing their
watersheds defines a partition of the terrain into sink-watersheds.
In general a watershed can be defined by an outlet point. Depending on how
the outlet point is chosen, the watershed is larger or smaller.
r.watershed solves a more general problem of partitioning the terrain
into watersheds of arbitrary outlets (not necessarily sinks) and of a
given (approximate) size. The problem is how to choose the outlets
in order to have the watersheds define a partition and have approximately
the specified size. This is a different problem that computing
flow direction and flow accumulation. r.terraflow does not do that (yet)
-- but we are working on extending it with this functionality.
(c) "Flooding produces a sink-less terrain in which every cell has a
downslope flow path leading outside the terrain ..." -- Does this mean that
all internal no-outlet subbasins (like catchment of a no-outlet lake) are
filled in?
Depends what you mean by "filled in". There are 2 options:
(1) either water (and thus flow direction) stops in sinks
(2) or water escapes the sink by going upslope. If the water goes
upslope, then it follows the lowest path to the edge of the terrain.
We think of flooding (filling the sink-watersheds) as a technique for
finding lowest paths and assiging upslope flow directions. That is,
one can assign downslope FD on the flooded terrain and map them back onto
the original terrain. It does not mean that the terrain has actually been
flooded.
(d) I used a float DEM and my output flooded (I think it's clearer to call it
sinkless or depressionless) DEM is a CELL. Why not FCELL, for computational
and storage reasons?
yes. we did not expect that the flooded terrain would be actually used.
I hope I don't come accross as nagging or unappreciative! You've done a great
work, I just thought I'd put in my 0.05cThank you,
AlekseyOn Monday 09 June 2003 06:54 pm, Helena wrote:
> The new version that compiles under gcc3.2 is at
> http://www.cs.duke.edu/~laura/bin/
>
> I did not have time to try it out and submit it,
> so if you can test this latest version that would help. Also, let us
> know if you
> have any questions - it is still a work in progress.
> Glynn is right that it belongs to the GRASS development version and
> the previous version of r.terraflow is in src.contrib/DUKE
>
>
> Helena
Glynn,
as I understand it the changes in the Gmakefile were made in response to Aleksey's email (see below). The tar-ball that I gave to Markus is the one from June that Laura refers to in her message, while the version in the CVS is couple months older and supposedly had the problem compiling on Mandrake. If the current Gmakefile is better than the new one then of course it should stay.
I am cc this to Laura, hopefully she will be able to advice us on this.
Helena
Glynn wrote:
Don't update the Gmakefile; the one in CVS is correct (well, it isn't
correct, but it's an improvement over the updated version).
Laura I. Toma wrote:
Dear Aleksey,
Thanks for your feedback. I asnwered some of your comments below. We'll
try to make the html page clearer.I put a new tar-ball at
http://www.cs.duke.edu/~laura/bin/
-LauraOn Thu, 12 Jun 2003, Aleksey Naumov wrote:
Dear Helena and Laura,
Thank you for the great work on r.terraflow! It seems fast and well done. I
checked out version 1.5 and here is some feedback.Ver. 1.5 compiled fine on my Mandrake 9.1 (GCC 3.2.2), with CVS GRASS, however
I had to do some manual editing. Specifying --with-cxx configure option was
not enough, I got "Compilation error in module: src.contrib/DUKE/r.terraflow
(ignored)".
The problem was with file paths in IOStream/lib/src/*.d files which are set
for a RedHat system. Once I changed redhat-specific paths to their mandrake
equivalents:
(a) /usr/lib/gcc-lib/i386-redhat-linux/3.2 =>
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2
(b) /usr/include/c++/3.2/i386-redhat-linux =>
/usr/include/c++/3.2.2/i586-mandrake-linux-gnu
everything compiled ok. I suppose this sort of thing will require more
C++-specific configure checks which probably won't be really needed until
5.1.the *.d files in IOSTREAM are generated automatically. my mistake
not to clean up before making the tar ball. Should work if you delete them
and try compiling again from scratch.The rest of this is mostly about the HTML document page, with some general
questions/suggestions...1. The "elev" argument is incorrectly documented as "elevin"
fixed.
2. The HTML page seems confusing to me in the part explaining flooding and
sinks:
(a) "swatershed" output is described as "output sink-watershed raster", yet
what it really seems to hold is a map of subwatersheds. Using "sink" is
really confusing here, since it most commonly means a point from which there
is no outflow (and this is how sinks are described in the text just above --
as "areas that do not spill out"). Why not call it "watershed" and describe
as a map that holds small subwatersheds?(b) BTW, what controls the size of those subwatersheds saved in the
"swatershed" map? (Something similat to "threshold" in r.watershed may be
nice...)In Terraflow the watershed of a sink represents the *entire* area that
flows into the sink. Basically each sink-watershed represents a bucket in
the ground that will fill with water when it rains (long enough). Each
sink-watershed is well-defined, and does not depend on the choice of a
threshold. Selecting all the sinks in the terrain and computing their
watersheds defines a partition of the terrain into sink-watersheds.In general a watershed can be defined by an outlet point. Depending on how
the outlet point is chosen, the watershed is larger or smaller.
r.watershed solves a more general problem of partitioning the terrain
into watersheds of arbitrary outlets (not necessarily sinks) and of a
given (approximate) size. The problem is how to choose the outlets
in order to have the watersheds define a partition and have approximately
the specified size. This is a different problem that computing
flow direction and flow accumulation. r.terraflow does not do that (yet)
-- but we are working on extending it with this functionality.(c) "Flooding produces a sink-less terrain in which every cell has a
downslope flow path leading outside the terrain ..." -- Does this mean that
all internal no-outlet subbasins (like catchment of a no-outlet lake) are
filled in?Depends what you mean by "filled in". There are 2 options:
(1) either water (and thus flow direction) stops in sinks
(2) or water escapes the sink by going upslope. If the water goes
upslope, then it follows the lowest path to the edge of the terrain.
We think of flooding (filling the sink-watersheds) as a technique for
finding lowest paths and assiging upslope flow directions. That is,
one can assign downslope FD on the flooded terrain and map them back onto
the original terrain. It does not mean that the terrain has actually been
flooded.(d) I used a float DEM and my output flooded (I think it's clearer to call it
sinkless or depressionless) DEM is a CELL. Why not FCELL, for computational
and storage reasons?yes. we did not expect that the flooded terrain would be actually used.
I hope I don't come accross as nagging or unappreciative! You've done a great
work, I just thought I'd put in my 0.05cThank you,
AlekseyOn Monday 09 June 2003 06:54 pm, Helena wrote:
The new version that compiles under gcc3.2 is at
http://www.cs.duke.edu/~laura/bin/I did not have time to try it out and submit it,
so if you can test this latest version that would help. Also, let us
know if you
have any questions - it is still a work in progress.
Glynn is right that it belongs to the GRASS development version and
the previous version of r.terraflow is in src.contrib/DUKEHelena
Helena wrote:
as I understand it the changes in the Gmakefile were made in response to
Aleksey's email (see below).
None of the Gmakefile changes in the diff which Hamish posted will
have any effect upon Aleksey's problems.
In fact, Aleksey's problem (invalid .d files) shouldn't be relevant to
the GRASS distribution, which shouldn't contain any .d files. My guess
is that someone used "make srcdist" from a tree which had the .d files
lying around ("make distclean" won't delete them; they have to be
deleted manually).
--
Glynn Clements <glynn.clements@virgin.net>
I am not sure I understand what the problem is.. This is the update about r.terraflow:
-version 1.4 does not compile with gcc3.2.
-version 1.5 does.
-functionality is the same, some files in 1.5 have changed to gcc3.2 requirements
-the only difference in the Gmakefiles is that 1.5 contains the additional compile flag Wno-deprecated
-both versions tar-balls can be found at
http://www.cs.duke.edu/geo*/terraflow/r.terraflow.1.4.tar.gz <http://www.cs.duke.edu/geo*/terraflow/terraflow-grass.html>
http://www.cs.duke.edu/geo*/terraflow/r.terraflow.1.5.tar.gz <http://www.cs.duke.edu/geo*/terraflow/terraflow-grass.html>
I downloaded grass-5.0.3rc2 and it looks like it contains version 1.4. Is there a reason for this? If not, it should be updated. It would be simpler if I had CVS rights, but I never got around to doing that..sorry.
-Laura
Helena wrote:
Glynn,
as I understand it the changes in the Gmakefile were made in response to Aleksey's email (see below). The tar-ball that I gave to Markus is the one from June that Laura refers to in her message, while the version in the CVS is couple months older and supposedly had the problem compiling on Mandrake. If the current Gmakefile is better than the new one then of course it should stay.
I am cc this to Laura, hopefully she will be able to advice us on this.
Helena
Glynn wrote:
Don't update the Gmakefile; the one in CVS is correct (well, it isn't
correct, but it's an improvement over the updated version).Laura I. Toma wrote:
Dear Aleksey,
Thanks for your feedback. I asnwered some of your comments below. We'll
try to make the html page clearer.I put a new tar-ball at
http://www.cs.duke.edu/~laura/bin/
-LauraOn Thu, 12 Jun 2003, Aleksey Naumov wrote:
Dear Helena and Laura,
Thank you for the great work on r.terraflow! It seems fast and well done. I
checked out version 1.5 and here is some feedback.Ver. 1.5 compiled fine on my Mandrake 9.1 (GCC 3.2.2), with CVS GRASS, however
I had to do some manual editing. Specifying --with-cxx configure option was
not enough, I got "Compilation error in module: src.contrib/DUKE/r.terraflow
(ignored)".
The problem was with file paths in IOStream/lib/src/*.d files which are set
for a RedHat system. Once I changed redhat-specific paths to their mandrake
equivalents:
(a) /usr/lib/gcc-lib/i386-redhat-linux/3.2 =>
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2
(b) /usr/include/c++/3.2/i386-redhat-linux =>
/usr/include/c++/3.2.2/i586-mandrake-linux-gnu
everything compiled ok. I suppose this sort of thing will require more
C++-specific configure checks which probably won't be really needed until
5.1.the *.d files in IOSTREAM are generated automatically. my mistake
not to clean up before making the tar ball. Should work if you delete them
and try compiling again from scratch.The rest of this is mostly about the HTML document page, with some general
questions/suggestions...1. The "elev" argument is incorrectly documented as "elevin"
fixed.
2. The HTML page seems confusing to me in the part explaining flooding and
sinks:
(a) "swatershed" output is described as "output sink-watershed raster", yet
what it really seems to hold is a map of subwatersheds. Using "sink" is
really confusing here, since it most commonly means a point from which there
is no outflow (and this is how sinks are described in the text just above --
as "areas that do not spill out"). Why not call it "watershed" and describe
as a map that holds small subwatersheds?(b) BTW, what controls the size of those subwatersheds saved in the
"swatershed" map? (Something similat to "threshold" in r.watershed may be
nice...)In Terraflow the watershed of a sink represents the *entire* area that
flows into the sink. Basically each sink-watershed represents a bucket in
the ground that will fill with water when it rains (long enough). Each
sink-watershed is well-defined, and does not depend on the choice of a
threshold. Selecting all the sinks in the terrain and computing their
watersheds defines a partition of the terrain into sink-watersheds.In general a watershed can be defined by an outlet point. Depending on how
the outlet point is chosen, the watershed is larger or smaller.
r.watershed solves a more general problem of partitioning the terrain
into watersheds of arbitrary outlets (not necessarily sinks) and of a
given (approximate) size. The problem is how to choose the outlets
in order to have the watersheds define a partition and have approximately
the specified size. This is a different problem that computing
flow direction and flow accumulation. r.terraflow does not do that (yet)
-- but we are working on extending it with this functionality.(c) "Flooding produces a sink-less terrain in which every cell has a
downslope flow path leading outside the terrain ..." -- Does this mean that
all internal no-outlet subbasins (like catchment of a no-outlet lake) are
filled in?Depends what you mean by "filled in". There are 2 options:
(1) either water (and thus flow direction) stops in sinks
(2) or water escapes the sink by going upslope. If the water goes
upslope, then it follows the lowest path to the edge of the terrain.
We think of flooding (filling the sink-watersheds) as a technique for
finding lowest paths and assiging upslope flow directions. That is,
one can assign downslope FD on the flooded terrain and map them back onto
the original terrain. It does not mean that the terrain has actually been
flooded.(d) I used a float DEM and my output flooded (I think it's clearer to call it
sinkless or depressionless) DEM is a CELL. Why not FCELL, for computational
and storage reasons?yes. we did not expect that the flooded terrain would be actually used.
I hope I don't come accross as nagging or unappreciative! You've done a great
work, I just thought I'd put in my 0.05cThank you,
AlekseyOn Monday 09 June 2003 06:54 pm, Helena wrote:
The new version that compiles under gcc3.2 is at
http://www.cs.duke.edu/~laura/bin/I did not have time to try it out and submit it,
so if you can test this latest version that would help. Also, let us
know if you
have any questions - it is still a work in progress.
Glynn is right that it belongs to the GRASS development version and
the previous version of r.terraflow is in src.contrib/DUKEHelena
Laura Toma wrote:
I am not sure I understand what the problem is.. This is the update
about r.terraflow:
-version 1.4 does not compile with gcc3.2.
-version 1.5 does.
-functionality is the same, some files in 1.5 have changed to gcc3.2
requirements
-the only difference in the Gmakefiles is that 1.5 contains the
additional compile flag Wno-deprecated
It appears that Hamish made the patch between the version in GRASS CVS
and the 1.5 tarball. The CVS version includes some fixes to the
original version (presumably 1.4), so his patch would effectively undo
those fixes.
What should be done is to produce a patch between the unmodified 1.4
and 1.5 versions, then to apply that patch to the CVS version. That
should produce a version which includes both the fixes and the
1.4->1.5 changes.
--
Glynn Clements <glynn.clements@virgin.net>
I downloaded grass-5.0.3rc2 and looked at the code in src.contrib.DUKE/r.terraflow/ and there dont seem to be many changes:
$diff grass-5.0.3rc2/src.contrib/DUKE/r.terraflow/Gmakefile ~/r.terraflow.1.5/Gmakefile
45c45
< CFLAGS += -Wall -I$(IOSTREAM_INC)
-------
> CFLAGS += -Wall -I$(IOSTREAM_INC) -Wno-deprecated
$
$diff grass-5.0.3rc2/src.contrib/DUKE/r.terraflow/Gmakefile ~/r.terraflow.1.4/Gmakefile
59,60c59,60
< -mkdir $(OBJARCH)/FLOAT ; true
< -mkdir $(OBJARCH)/SHORT ; true
-------
< -mkdir $(OBJARCH)/FLOAT
$
Are these all the fixes? Where is the patch located? How can i look at the fixes? Do I need to compile grass to see them? Does r.terraflow get compiled when installing grass, or, one has to run Gmakefile in r.terraflwo directory (this is the way it used to be) ?
thanks,
Laura
Glynn Clements wrote:
Laura Toma wrote:
I am not sure I understand what the problem is.. This is the update about r.terraflow:
-version 1.4 does not compile with gcc3.2.
-version 1.5 does.
-functionality is the same, some files in 1.5 have changed to gcc3.2 requirements
-the only difference in the Gmakefiles is that 1.5 contains the additional compile flag Wno-deprecated
It appears that Hamish made the patch between the version in GRASS CVS
and the 1.5 tarball. The CVS version includes some fixes to the
original version (presumably 1.4), so his patch would effectively undo
those fixes.What should be done is to produce a patch between the unmodified 1.4
and 1.5 versions, then to apply that patch to the CVS version. That
should produce a version which includes both the fixes and the
1.4->1.5 changes.
Laura Toma wrote:
I downloaded grass-5.0.3rc2 and looked at the code in
src.contrib.DUKE/r.terraflow/ and there dont seem to be many changes:
There have been two sets of fixes to the Gmakefile, neither of which
have made it into the release branch (i.e. 5.0.3rc2).
$diff grass-5.0.3rc2/src.contrib/DUKE/r.terraflow/Gmakefile
~/r.terraflow.1.5/Gmakefile
45c45
< CFLAGS += -Wall -I$(IOSTREAM_INC)
-------
> CFLAGS += -Wall -I$(IOSTREAM_INC) -Wno-deprecated
$$diff grass-5.0.3rc2/src.contrib/DUKE/r.terraflow/Gmakefile
~/r.terraflow.1.4/Gmakefile
59,60c59,60
< -mkdir $(OBJARCH)/FLOAT ; true
< -mkdir $(OBJARCH)/SHORT ; true
-------
< -mkdir $(OBJARCH)/FLOAT
< -mkdir $(OBJARCH)/FLOAT
$Are these all the fixes?
No.
Where is the patch located?
I was referring to one which Hamish posted to the developers' list;
the archive URL is:
http://grass.itc.it/pipermail/grass5/2003-September/006268.html
but the patch itself was included as a MIME attachment, so it can't
easily be read via that URL (you would have to manually decode it with
e.g. mmencode).
How can i look at the fixes?
cvs diff -r 1.1 -r 1.3 src.contrib/DUKE/r.terraflow/Gmakefile
Basically, the main issue is using $(CXX) instead of $(CC) and
$(CXXFLAGS) instead of $(CFLAGS). Both of these are now set by the
configure script (in the CVS HEAD version; the release branch doesn't
have either the r.terraflow/Gmakefile changes or the build system
changes which are required to support C++ code).
Do I need to compile grass to see them? Does r.terraflow get
compiled when installing grass, or, one has to run Gmakefile in
r.terraflwo directory (this is the way it used to be) ?
With the CVS HEAD version, if you use the --with-cxx configure switch,
r.terraflow will be built automatically. With the version in the
release branch, you have to build it separately with gmake5.
--
Glynn Clements <glynn.clements@virgin.net>
Glynn
could you please update the release_branch if desired?
I would like to get out 5.0.3RC4 today (the NVIZ patch is applied).
Thanks,
Markus
On Fri, Sep 19, 2003 at 04:15:02AM +0100, Glynn Clements wrote:
Laura Toma wrote:
> I downloaded grass-5.0.3rc2 and looked at the code in
> src.contrib.DUKE/r.terraflow/ and there dont seem to be many changes:There have been two sets of fixes to the Gmakefile, neither of which
have made it into the release branch (i.e. 5.0.3rc2).> $diff grass-5.0.3rc2/src.contrib/DUKE/r.terraflow/Gmakefile
> ~/r.terraflow.1.5/Gmakefile
> 45c45
> < CFLAGS += -Wall -I$(IOSTREAM_INC)
> -------
> > CFLAGS += -Wall -I$(IOSTREAM_INC) -Wno-deprecated
> $
>
>
> $diff grass-5.0.3rc2/src.contrib/DUKE/r.terraflow/Gmakefile
> ~/r.terraflow.1.4/Gmakefile
> 59,60c59,60
> < -mkdir $(OBJARCH)/FLOAT ; true
> < -mkdir $(OBJARCH)/SHORT ; true
> -------
> < -mkdir $(OBJARCH)/FLOAT
> < -mkdir $(OBJARCH)/FLOAT
> $
>
> Are these all the fixes?No.
> Where is the patch located?
I was referring to one which Hamish posted to the developers' list;
the archive URL is:http://grass.itc.it/pipermail/grass5/2003-September/006268.html
but the patch itself was included as a MIME attachment, so it can't
easily be read via that URL (you would have to manually decode it with
e.g. mmencode).> How can i look at the fixes?
cvs diff -r 1.1 -r 1.3 src.contrib/DUKE/r.terraflow/Gmakefile
Basically, the main issue is using $(CXX) instead of $(CC) and
$(CXXFLAGS) instead of $(CFLAGS). Both of these are now set by the
configure script (in the CVS HEAD version; the release branch doesn't
have either the r.terraflow/Gmakefile changes or the build system
changes which are required to support C++ code).> Do I need to compile grass to see them? Does r.terraflow get
> compiled when installing grass, or, one has to run Gmakefile in
> r.terraflwo directory (this is the way it used to be) ?With the CVS HEAD version, if you use the --with-cxx configure switch,
r.terraflow will be built automatically. With the version in the
release branch, you have to build it separately with gmake5.--
Glynn Clements <glynn.clements@virgin.net>
On Fri, 19 Sep 2003, Markus Neteler wrote:
Glynn
could you please update the release_branch if desired?
I think Helena said before that r.terraflow should not even be in the
release branch as it is a new experimental program (are the C++ compiler
changes even in the release branch?)---I agree---I think it should just be
removed from the release branch to make things simpler.
Paul
Paul is right - r.terraflow certainly is not a bugfix but a brand new module and if I understand the releases correctly it should go into 5.3.
Anybody who needs it right now can get the CVS HEAD GRASS
Helena
Paul Kelly wrote:
On Fri, 19 Sep 2003, Markus Neteler wrote:
Glynn
could you please update the release_branch if desired?
I think Helena said before that r.terraflow should not even be in the
release branch as it is a new experimental program (are the C++ compiler
changes even in the release branch?)---I agree---I think it should just be
removed from the release branch to make things simpler.Paul
Laura Toma wrote:
> I am not sure I understand what the problem is.. This is the update
> about r.terraflow:
> -version 1.4 does not compile with gcc3.2.
> -version 1.5 does.
> -functionality is the same, some files in 1.5 have changed to gcc3.2
> requirements
> -the only difference in the Gmakefiles is that 1.5 contains the
> additional compile flag Wno-deprecatedIt appears that Hamish made the patch between the version in GRASS CVS
and the 1.5 tarball. The CVS version includes some fixes to the
original version (presumably 1.4), so his patch would effectively undo
those fixes.
Yes, that is correct.
Hamish
What should be done is to produce a patch between the unmodified 1.4
and 1.5 versions, then to apply that patch to the CVS version. That
should produce a version which includes both the fixes and the
1.4->1.5 changes.
Here is a diff between r.terraflow versions 1.4 and 1.5 as downloaded
from Laura's webpage:
http://bambi.otago.ac.nz/hamish/grass/r.terraflow1.4_1.5.diff
http://www.cs.duke.edu/geo*/terraflow/r.terraflow.1.4.tar.gz
http://www.cs.duke.edu/geo*/terraflow/r.terraflow.1.5.tar.gz
[note "r.terraflow/" moved to "r.terraflow.1.4/" for diff]
Hamish
On Fri, Sep 19, 2003 at 08:07:05AM -0400, Helena wrote:
Paul is right - r.terraflow certainly is not a bugfix but a brand new
module and if I understand the releases correctly it should go into 5.3.
Anybody who needs it right now can get the CVS HEAD GRASS
How to remove r.terraflow from the release_branch?
Could anyone knowing that perform this?
thanks,
Markus