[GRASS-dev] r.terraflow on Mac OS X 10.4.9

Jeshua_Lacock · July 26, 2007, 9:48am

I just built 6.2.2 with one failed module here on Mac OS X:

make[2]: *** No rule to make target `/usr/include/gcc/darwin/4.0/c++/iostream', needed by `ami_stream.d'. Stop.
make[1]: *** [build] Error 2
make: *** [/usr/src/openosx-grass-autobuild/src/grass-6.2.1/dist.powerpc-apple-darwin8.9.0/bin/r.terraflow] Error 2

On my machine "/usr/include/gcc/darwin/4.0/c++/iostream" is "/usr/include//c++/4.0.0/iostream".

After replacing about 20 lines in `ami_stream.d' it started having similar problems with `mm_utils.d'.

Can anyone advise how were those ".d" files generated? Or do I have to fix one line at a time?

Thanks,

Jeshua Lacock, Owner
<http://OpenOSX.com>
phone: 877.240.1364

William_Kyngesburye · July 26, 2007, 2:21pm

It should work without patching anything. I've never had this problem with building GRASS 6.x. Do you have any unusual flags in your build?

You say 6.2.2, but the error says 6.2.1 - somehow the makefiles are crossing?

Have you customized your GCC installation at all? Mine is clean and is also /usr/include/c++/....

I wonder if it's trying to compile with 'gcc -x c++' instead of 'g++' (the /usr/include/gcc/... implies this). I've found that the two operate a little differently - 'g++' does some automatic include/link magic that 'gcc -x c++' doesn't.

On Jul 26, 2007, at 4:48 AM, Jeshua Lacock wrote:

I just built 6.2.2 with one failed module here on Mac OS X:

make[2]: *** No rule to make target `/usr/include/gcc/darwin/4.0/c++/iostream', needed by `ami_stream.d'. Stop.
make[1]: *** [build] Error 2
make: *** [/usr/src/openosx-grass-autobuild/src/grass-6.2.1/dist.powerpc-apple-darwin8.9.0/bin/r.terraflow] Error 2

On my machine "/usr/include/gcc/darwin/4.0/c++/iostream" is "/usr/include//c++/4.0.0/iostream".

After replacing about 20 lines in `ami_stream.d' it started having similar problems with `mm_utils.d'.

Can anyone advise how were those ".d" files generated? Or do I have to fix one line at a time?

Thanks,

Jeshua Lacock, Owner
<http://OpenOSX.com>
phone: 877.240.1364

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect

Glynn_Clements1 · July 26, 2007, 9:29pm

Jeshua Lacock wrote:

I just built 6.2.2 with one failed module here on Mac OS X:

make[2]: *** No rule to make target `/usr/include/gcc/darwin/4.0/c++/
iostream', needed by `ami_stream.d'. Stop.
make[1]: *** [build] Error 2
make: *** [/usr/src/openosx-grass-autobuild/src/grass-6.2.1/
dist.powerpc-apple-darwin8.9.0/bin/r.terraflow] Error 2

On my machine "/usr/include/gcc/darwin/4.0/c++/iostream" is "/usr/
include//c++/4.0.0/iostream".

It appears that either the compiler has changed since it was last
built, or a partially-built code tree has been copied to a different
machine.

After replacing about 20 lines in `ami_stream.d' it started having
similar problems with `mm_utils.d'.

Just delete all of the .d files.

Can anyone advise how were those ".d" files generated?

With the following rule:

%.d: %.cc
$(SHELL) -ec '$(CXX) -M $(CPPFLAGS) $< | sed '\''s/$*.o/& $@/g'\'' > $@'

Or do I have to fix one line at a time?

The .d files aren't necessary. They will be built automatically, and
they should be removed automatically by "make clean".

In general, auto-generating dependency files is a bad idea, as it can
lead to this sort of problem when changes occur. Even if the Makefile
has rules which to clean and/or re-build the dependencies, stale
dependencies can prevent the Makefile from working.

Personally, I would just remove all references to .d files from
r.terraflow.

[Well, personally I would just remove r.terraflow, having been written
without any consideration for GRASS' build system or coding
conventions, or portability in general. But that's just me.]

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

Brad_Douglas · July 27, 2007, 12:18pm

On Thu, 2007-07-26 at 22:29 +0100, Glynn Clements wrote:

[Well, personally I would just remove r.terraflow, having been written
without any consideration for GRASS' build system or coding
conventions, or portability in general. But that's just me.]

I agree with the sentiment, but I don't know how practical that is at
the moment.

r.terraflow breaks often, has been a headache to maintain and the author
does not have the time/resources to keep it current. OTOH, it is a
useful module and is portable in the sense that there is a ArcGIS
version.

Perhaps relegate it to the SVN addon repository since it does break so
many GRASS conventions? I wish we had some statistics on module
frequency to determine how inconvenient such a move would be.
Personally, I've only used r.terraflow on occasion, but that type of
analysis is not my forte.

--
73, de Brad KB8UYR/6 <rez touchofmadness com>

cmbarton · July 27, 2007, 3:44pm

We're experimenting with r.terraflow as an alternative to r.flow for faster
computation of flow accumulation in a detailed erosion/deposition model
(based on USPED equations) we've recently posted on the SVN addons site. It
may give better results than r.flow in this context. But I agree that it has
been temperamental (though currently working OK under FC6). Helena mentioned
that a new and much improved version is in the works. So we might not want
to relegate it to the scrap heap yet.

Michael

On 7/27/07 5:18 AM, "Brad Douglas" <rez@touchofmadness.com> wrote:

On Thu, 2007-07-26 at 22:29 +0100, Glynn Clements wrote:

[Well, personally I would just remove r.terraflow, having been written
without any consideration for GRASS' build system or coding
conventions, or portability in general. But that's just me.]

I agree with the sentiment, but I don't know how practical that is at
the moment.

r.terraflow breaks often, has been a headache to maintain and the author
does not have the time/resources to keep it current. OTOH, it is a
useful module and is portable in the sense that there is a ArcGIS
version.

Perhaps relegate it to the SVN addon repository since it does break so
many GRASS conventions? I wish we had some statistics on module
frequency to determine how inconvenient such a move would be.
Personally, I've only used r.terraflow on occasion, but that type of
analysis is not my forte.

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Helena_Mitasova · July 27, 2007, 3:59pm

I need to finish some urgent work right now - I will provide a more
detailed answer later - for now : it will be retired but keep it there
for now because it is the only tool that has MFD and runs on large DEMs
that we have for now.

Helena

On Fri, 2007-07-27 at 08:44 -0700, Michael Barton wrote:

We're experimenting with r.terraflow as an alternative to r.flow for faster
computation of flow accumulation in a detailed erosion/deposition model
(based on USPED equations) we've recently posted on the SVN addons site. It
may give better results than r.flow in this context. But I agree that it has
been temperamental (though currently working OK under FC6). Helena mentioned
that a new and much improved version is in the works. So we might not want
to relegate it to the scrap heap yet.

Michael

On 7/27/07 5:18 AM, "Brad Douglas" <rez@touchofmadness.com> wrote:

> On Thu, 2007-07-26 at 22:29 +0100, Glynn Clements wrote:
>> [Well, personally I would just remove r.terraflow, having been written
>> without any consideration for GRASS' build system or coding
>> conventions, or portability in general. But that's just me.]
>
> I agree with the sentiment, but I don't know how practical that is at
> the moment.
>
> r.terraflow breaks often, has been a headache to maintain and the author
> does not have the time/resources to keep it current. OTOH, it is a
> useful module and is portable in the sense that there is a ArcGIS
> version.
>
> Perhaps relegate it to the SVN addon repository since it does break so
> many GRASS conventions? I wish we had some statistics on module
> frequency to determine how inconvenient such a move would be.
> Personally, I've only used r.terraflow on occasion, but that type of
> analysis is not my forte.
>

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

Glynn_Clements1 · July 28, 2007, 4:40am

Brad Douglas wrote:

> [Well, personally I would just remove r.terraflow, having been written
> without any consideration for GRASS' build system or coding
> conventions, or portability in general. But that's just me.]

I agree with the sentiment, but I don't know how practical that is at
the moment.

That comment was more just general complaining than actual advocacy of
such a step. The one factor in r.terraflow's favour is that the
problems with r.terraflow only affect r.terraflow itself. If they
affected anything else, it would be gone by now

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