[GRASS-dev] another make problem (OSX, but could be a general problem)

GRASS GIS GRASS GIS developer
1

Make now ALWAYS recompiles everything. I'm guessing it has something to do with the recent parallel build/recompile changes. My last cvs update was a week ago, and it was normal (a few would recompile regardless of the need, but not everything).

ie, from a distclean and configure:

make -> all GRASS is compiled
change a source file or makefile - or not, doesn't matter
make -> all recompiled

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

"Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence....

- the wisdom of Tarzan

2

William Kyngesburye wrote:

Make now ALWAYS recompiles everything.

I have the same issue on my Linux box.

Markus
--
View this message in context: http://www.nabble.com/another-make-problem-(OSX%2C-but-could-be-a-general-problem)-tf4551133.html#a12994710
Sent from the Grass - Dev mailing list archive at Nabble.com.

3

William Kyngesburye wrote:

Make now ALWAYS recompiles everything. I'm guessing it has something
to do with the recent parallel build/recompile changes. My last cvs
update was a week ago, and it was normal (a few would recompile
regardless of the need, but not everything).

ie, from a distclean and configure:

make -> all GRASS is compiled
change a source file or makefile - or not, doesn't matter
make -> all recompiled

Odd. Apart from the changes required to support parallel builds, I
also made some changes to prevent unnecessary recompilation.

For me, about the only part which is re-compiled is the message
catalogues.

I'll look into it, but it's going to be awkward if I can't reproduce
it.

A couple of questions:

1. Is this with a MacOSX App build? If so, do you get the same
behaviour with a non-App build?

2. Does it help if you change the following in Rules.make from:

$(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR)
  $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \
    -o $(OBJDIR)/$*.o -c $*.c

to:

$(OBJDIR)/%.o : %.c $(LOCAL_HEADERS)
  $(MKDIR) $(OBJDIR)
  $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \
    -o $(OBJDIR)/$*.o -c $*.c

?

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

4

On Oct 2, 2007, at 3:49 AM, Glynn Clements wrote:

A couple of questions:

1. Is this with a MacOSX App build? If so, do you get the same
behaviour with a non-App build?

Actually, yes. Before I fixed a small problem where the macosx dir didn't build, it was happening.

2. Does it help if you change the following in Rules.make from:

$(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR)
  $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \
    -o $(OBJDIR)/$*.o -c $*.c

to:

$(OBJDIR)/%.o : %.c $(LOCAL_HEADERS)
  $(MKDIR) $(OBJDIR)
  $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \
    -o $(OBJDIR)/$*.o -c $*.c

?

Much better. Still a few recompiles:

various copy files steps
libsqlp (recompile)
r.terraflow (recompile) (that has its own object targets with a similar "| $(OBJDIR)" in the target deps)
nviz (relink)
my OSX app build (relink) (my fault for how I set up the makefile)

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

"Time is an illusion - lunchtime doubly so."

- Ford Prefect

5

William Kyngesburye wrote:

> A couple of questions:
>
> 1. Is this with a MacOSX App build? If so, do you get the same
> behaviour with a non-App build?
>
Actually, yes. Before I fixed a small problem where the macosx dir
didn't build, it was happening.

Is that "yes" to the first or to the second, or both?

If this only happens with the App build, then it's (mainly) up to you
to solve. I can't test an App build, and it appears to be modifying
some of the *.make files.

For now, I'm only interested in issues which occur when using the
stock build system (i.e. no --enable-macosx-app).

> 2. Does it help if you change the following in Rules.make from:
>
> $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR)
> $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \
> -o $(OBJDIR)/$*.o -c $*.c
>
> to:
>
> $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS)
> $(MKDIR) $(OBJDIR)
> $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \
> -o $(OBJDIR)/$*.o -c $*.c
>
> ?

Much better.

Is the "make" program GNU make? Does it come via Apple? Can you try
building GNU make from the stock source package and using that?

Prerequisites listed to the right of "|" are "order-only"; if
necessary, they will be built before the target, but they won't cause
the target to be re-compiled.

If you're using something other than GNU make (which includes modified
versions if the modifications make a difference), then I can't really
help. I would rather not unconditionally run mkdir for every object
file if it's an issue with one particular make program.

Still a few recompiles:

various copy files steps
libsqlp (recompile)
r.terraflow (recompile) (that has its own object targets with a
similar "| $(OBJDIR)" in the target deps)
nviz (relink)
my OSX app build (relink) (my fault for how I set up the makefile)

The copying steps are a known issue. That's simple to fix; it just
means manually re-writing all of the individual targets. NVIZ is also
known; NVIZ has its own, non-standard build system which is a complete
mess, and I don't touch it if I don't need to.

I don't have the issues with r.terraflow (which also has its own,
non-standard build system) or sqlp (which is a normal library).

sqlp *might* be due to lex/yacc issues (that's the only part that's
different from other libraries). If yacc is being re-run, y.tab.h will
be updated, which will force the rest of it to be compiled.

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

6

On Oct 2, 2007, at 12:30 PM, Glynn Clements wrote:

William Kyngesburye wrote:

A couple of questions:

1. Is this with a MacOSX App build? If so, do you get the same
behaviour with a non-App build?

Actually, yes. Before I fixed a small problem where the macosx dir
didn't build, it was happening.

Is that "yes" to the first or to the second, or both?

If this only happens with the App build, then it's (mainly) up to you
to solve. I can't test an App build, and it appears to be modifying
some of the *.make files.

For now, I'm only interested in issues which occur when using the
stock build system (i.e. no --enable-macosx-app).

yes, without OSX app build - all that is really is just another subdir to make, so the libraries and modules are all stock GRASS.

2. Does it help if you change the following in Rules.make from:

$(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR)
  $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \
    -o $(OBJDIR)/$*.o -c $*.c

to:

$(OBJDIR)/%.o : %.c $(LOCAL_HEADERS)
  $(MKDIR) $(OBJDIR)
  $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \
    -o $(OBJDIR)/$*.o -c $*.c

?

Much better.

Is the "make" program GNU make? Does it come via Apple? Can you try
building GNU make from the stock source package and using that?

Prerequisites listed to the right of "|" are "order-only"; if
necessary, they will be built before the target, but they won't cause
the target to be re-compiled.

If you're using something other than GNU make (which includes modified
versions if the modifications make a difference), then I can't really
help. I would rather not unconditionally run mkdir for every object
file if it's an issue with one particular make program.

OSX Tiger/GCC 4 uses GNU Make 3.80. It doesn't look like Apple modified it (like they have for other stuff).

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

Theory of the Universe

There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened.

-Hitchhiker's Guide to the Galaxy 2nd season intro

7

William Kyngesburye wrote:

> Is the "make" program GNU make? Does it come via Apple? Can you try
> building GNU make from the stock source package and using that?
>
> Prerequisites listed to the right of "|" are "order-only"; if
> necessary, they will be built before the target, but they won't cause
> the target to be re-compiled.
>
> If you're using something other than GNU make (which includes modified
> versions if the modifications make a difference), then I can't really
> help. I would rather not unconditionally run mkdir for every object
> file if it's an issue with one particular make program.
>
OSX Tiger/GCC 4 uses GNU Make 3.80. It doesn't look like Apple
modified it (like they have for other stuff).

I have 3.81, and that's the only version for which I can find online
documentation.

Can you check the 3.80 documentation to ensure that order-only
prerequisites are mentioned? They should be described in:

  4 Writing Rules
  4.3 Types of Prerequisites

Other than that, I can only suggest re-building a directory with make
debugging enabled (make -d ...). It can generate a lot of output, so
pick the smallest case which demonstrates the problem (e.g. a module
with only one source file).

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

8

William Kyngesburye wrote:

On Oct 2, 2007, at 3:50 PM, Glynn Clements wrote:

> I have 3.81, and that's the only version for which I can find online
> documentation.
>
> Can you check the 3.80 documentation to ensure that order-only
> prerequisites are mentioned? They should be described in:
>
> 4 Writing Rules
> 4.3 Types of Prerequisites
>
Yep, it's there.

> Other than that, I can only suggest re-building a directory with make
> debugging enabled (make -d ...). It can generate a lot of output, so
> pick the smallest case which demonstrates the problem (e.g. a module
> with only one source file).
>

I picked the datetime lib (the first module I tried *didn't* recompile).

           Prerequisite `OBJ.i686-apple-darwin8.10.1' is newer than target `OBJ.i686-apple-darwin8.10.1/between.o'.
          Must remake target `OBJ.i686-apple-darwin8.10.1/between.o'.

This suggests a bug with order-only dependencies. The whole point of
order-only dependencies is that make only considers their existence;
the timestamp is supposed to be ignored.

Interesting - on a closer look, it seems to be completely recompiling
libraries, but only relinking programs. That's with a make at the
top level.

If I make an individual library, it also completely recompiles. But
re-making an individual program doesn't even relink, this seems to be
the only correct case.

That's particularly strange. The only rule which has $(OBJDIR) as a
prerequisite is the one to build object files (in Rules.make):

# default cc rules
$(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR)
  $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \
    -o $(OBJDIR)/$*.o -c $*.c

But that rule is used for libraries and modules alike. I have no idea
why it would behave differently for libraries and for modules.

Everything points to this being a "make" bug. Can you try with 3.81 to
see if it happens there?

Before that, can you try using "make -p" on both a library and a
module?

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

9

On Oct 3, 2007, at 4:10 AM, Glynn Clements wrote:

But that rule is used for libraries and modules alike. I have no idea
why it would behave differently for libraries and for modules.

Everything points to this being a "make" bug. Can you try with 3.81 to
see if it happens there?

3.81 works. There were a couple rebuilds, but that may have been from earlier rebuilds, like sqlp. I verified by building 3.80 from source (complete rebuild, so Apple didn't do anything to make).

So, looks like there may have been some bugs in 3.80. But, your average Mac user is not going to want to install a current make. And, since Markus had the same problem, there may be Linux distros that have an older make in their package manager.

Before that, can you try using "make -p" on both a library and a
module?

I remembered to zip it this time :slight_smile:

(attachments)

makedb.txt.zip (12.3 KB)

10

William Kyngesburye wrote:

> But that rule is used for libraries and modules alike. I have no idea
> why it would behave differently for libraries and for modules.
>
> Everything points to this being a "make" bug. Can you try with 3.81 to
> see if it happens there?

3.81 works. There were a couple rebuilds, but that may have been
from earlier rebuilds, like sqlp. I verified by building 3.80 from
source (complete rebuild, so Apple didn't do anything to make).

So, looks like there may have been some bugs in 3.80. But, your
average Mac user is not going to want to install a current make.

A "user" won't care about incremental rebuilds not actually being
incremental. They'll "configure; make; make install" then not compile
it again (at least, not without [dist]clean first).

And, since Markus had the same problem, there may be Linux distros
that have an older make in their package manager.

I missed that.

> Before that, can you try using "make -p" on both a library and a
> module?

I remembered to zip it this time :slight_smile:

That has the advantage that your message also gets posted to the list
rather than being bounced for being too large.

Your output has:

  # Implicit Rules
  
  OBJ.i686-apple-darwin8.10.1/%.o: %.c OBJ.i686-apple-darwin8.10.1
  # commands to execute (from `../../include/Make/Rules.make', line 23):
          $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \
          -o $(OBJDIR)/$*.o -c $*.c

while for "make -n -p -C lib/datetime" I get:

  # Implicit Rules
  
  OBJ.i686-pc-linux-gnu/%.o: %.c | OBJ.i686-pc-linux-gnu
  # commands to execute (from `../../include/Make/Rules.make', line 21):
    $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \
    -o $(OBJDIR)/$*.o -c $*.c

Note the vertical bar is missing from yours. Can you try the same
thing with a module (which doesn't re-compile everything)?

If the vertical bar is present for modules and missing for libraries,
It may be worth changing the placement of the "include .../Rules.make"
in the Lib.make and Module.make files, to see if there's some
combination that consistently avoids the bug.

I don't particularly want to build $(OBJDIR) "transparently" as part
of the %.o:%.c rule, as there is a race condition with parallel builds
(multiple processes may try to build the directory concurrently; mkdir
considers this a failure).

Also, it may be a performance issue on Cygwin. Cygwin's directory
operations are extremely inefficient; on a P4/3000, it's quicker to
mount the drive via SMB to my P3/800 Linux box and run find/ls/etc
there than it is to run the Cygwin versions locally.

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

11

On Oct 3, 2007, at 1:10 PM, Glynn Clements wrote:

A "user" won't care about incremental rebuilds not actually being
incremental. They'll "configure; make; make install" then not compile
it again (at least, not without [dist]clean first).

True. If it's unfixable, I can keep using the current up-to-date make. We'd have to recommend to other devs to update their make.

And, since Markus had the same problem, there may be Linux distros
that have an older make in their package manager.

I missed that.

http://grass.itc.it/pipermail/grass-dev/2007-October/033237.html

Note the vertical bar is missing from yours. Can you try the same
thing with a module (which doesn't re-compile everything)?

It's also missing the pipe:

(attachments)

makedb_mod.txt.zip (11.6 KB)

12

William Kyngesburye wrote:

> Note the vertical bar is missing from yours. Can you try the same
> thing with a module (which doesn't re-compile everything)?

It's also missing the pipe:

It's missing, but that case *doesn't* recompile everything? Ugh; this
is getting confusing.

I preceded the pipe with a backslash in Rules.make - now it keeps the
pipe and libraries aren't recompiled. But, this doesn't work in
3.81, so it doesn't look like a usable solution.

Okay, how about this:

# default cc rules
ifeq ($(MAKE_VERSION),3.81)
$(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR)
  $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \
    -o $(OBJDIR)/$*.o -c $*.c
else
$(OBJDIR)/%.o : %.c $(LOCAL_HEADERS)
  $(MAKE) $(OBJDIR)
  $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \
    -o $(OBJDIR)/$*.o -c $*.c
endif

?

This is less than ideal, as it will revert to the old form for 3.82,
but I can't think of a simple way to check for >= 3.81 (especially
considering that the version might not actually be a number, e.g.
3.81-r1 or similar).

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

13

Glynn Clements wrote:

sqlp *might* be due to lex/yacc issues (that's the only part that's
different from other libraries).

It was due to lex/yacc issues.

If yacc is being re-run, y.tab.h will
be updated, which will force the rest of it to be compiled.

What was happening is that Rules.make has:

  ifndef LOCAL_HEADERS
  LOCAL_HEADERS = $(wildcard *.h)
  endif
and:
  $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR)

On initial compilation, y.tab.h doesn't exist, so it isn't included in
$(LOCAL_HEADERS).

[This is a common pitfall of using $(wildcard ...). It only returns
what exists right now, omitting files which may be generated later.]

If $(OBJDIR)/y.tab.o isn't the first object file, then y.tab.h may[1]
end up being newer than some of the object files. On a second run,
y.tab.h is now a dependency for all object files, so any which are
older than y.tab.h will be re-compiled.

[1] File timestamps typically have a resolution of one second, so it's
probabilistic as to whether it's actually older.

The fix was to add $(EXTRA_HEADERS) as a dependency of $(OBJDIR)/%.o,
so that y.tab.h can be added even when it doesn't exist. This will
force y.tab.h to be generated before any of the object files, so
y.tab.h will be older.

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

14

On Oct 4, 2007, at 6:53 AM, Glynn Clements wrote:

William Kyngesburye wrote:

Note the vertical bar is missing from yours. Can you try the same
thing with a module (which doesn't re-compile everything)?

It's also missing the pipe:

It's missing, but that case *doesn't* recompile everything? Ugh; this
is getting confusing.

Indeed, very strange. Odd that it took them 4 years to release 3.81 with that fixed.

I preceded the pipe with a backslash in Rules.make - now it keeps the
pipe and libraries aren't recompiled. But, this doesn't work in
3.81, so it doesn't look like a usable solution.

Okay, how about this:

# default cc rules
ifeq ($(MAKE_VERSION),3.81)
$(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR)
  $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \
    -o $(OBJDIR)/$*.o -c $*.c
else
$(OBJDIR)/%.o : %.c $(LOCAL_HEADERS)
  $(MAKE) $(OBJDIR)
  $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \
    -o $(OBJDIR)/$*.o -c $*.c
endif

?

This is less than ideal, as it will revert to the old form for 3.82,
but I can't think of a simple way to check for >= 3.81 (especially
considering that the version might not actually be a number, e.g.
3.81-r1 or similar).

That works, but ugly and doesn't cover the future is probably not what we want to do. (I saw some .1 versions in the make downloads)

I'd be happy with the unconditional pipe and recommending to developers to upgrade their make and not worrying about the 1-shot user builds.

Markus: have you been following this? What's your make version, and does your linux package manager have a new version? Or is it otherwise easily updated?

I wonder what version other linux distros are at?

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

[Trillian] What are you supposed to do WITH a maniacally depressed robot?

[Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer...

- HitchHiker's Guide to the Galaxy

15

On Oct 4, 2007, at 10:27 , William Kyngesburye wrote:

This is less than ideal, as it will revert to the old form for 3.82,
but I can't think of a simple way to check for >= 3.81 (especially
considering that the version might not actually be a number, e.g.
3.81-r1 or similar).

That works, but ugly and doesn't cover the future is probably not what we want to do. (I saw some .1 versions in the make downloads)

I'd be happy with the unconditional pipe and recommending to developers to upgrade their make and not worrying about the 1-shot user builds.

...

I wonder what version other linux distros are at?

Ugh, all my machines use 3.80

Debian 3.1, Fedora 5, MacOSX Tiger

BUT I've been conservative with my upgrades, leading to package databases that are no longer actively maintained. Debian 4.0 is the current stable, and it's at make 3.81-2. Fedora 7 also uses 3.81.

So if Apple would just update the Dev Tools, we wouldn't need to install our own, but that's (I'm guessing) waiting for the new OS release.

I guess I should find some time for upgrades.

Cheers,
Scott

16

William Kyngesburye wrote:

Indeed, very strange. Odd that it took them 4 years to release 3.81
with that fixed.

I'd be a bit surprised if there a make bug could survive for that long which
wasn't widely known and we happened to be one of the few software builds
affected by it.

I'd be happy with the unconditional pipe and recommending to
developers to upgrade their make and not worrying about the 1-shot
user builds.

Maybe not as much for Mac-land, but for othe UNIXs worrying about self compiles
is a big deal.

I wonder what version other linux distros are at?

Debian Etch (stable): 3.81-2
Debian Sarge (old stable): 3.80-9
Debian unstable: 3.81-3

latest CVS builds fine on Etch, and it did work fine on Sarge last time I
tried. I can try again on Sarge with the latest CVS if it helps, let me know.

Hamish

      ____________________________________________________________________________________
Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos.
http://autos.yahoo.com/index.html

17

On Oct 4, 2007, at 9:08 PM, Scott Mitchell wrote:

I wonder what version other linux distros are at?

Ugh, all my machines use 3.80

Debian 3.1, Fedora 5, MacOSX Tiger

So, do you have the incremental compile problem on any of these? If you run make immediately after a successful make, does it recompile everything?

BUT I've been conservative with my upgrades, leading to package databases that are no longer actively maintained. Debian 4.0 is the current stable, and it's at make 3.81-2. Fedora 7 also uses 3.81.

So if Apple would just update the Dev Tools, we wouldn't need to install our own, but that's (I'm guessing) waiting for the new OS release.

yeah, hopefully Apple updates make in Leopard. I think Apple aims for stability thru the life of the major OS version. Towards the end of the version lifecycle things can seem wildly out of date, and Tiger has had an unusually long life.

On Oct 6, 2007, at 10:05 PM, Hamish wrote:

William Kyngesburye wrote:

I'd be happy with the unconditional pipe and recommending to
developers to upgrade their make and not worrying about the 1-shot
user builds.

Maybe not as much for Mac-land, but for othe UNIXs worrying about self compiles
is a big deal.

Well, I think on any system it's not a big problem when you just configure-make-install - you don't see the problem. That's what I meant by a 1-shot build.

I wonder what version other linux distros are at?

Debian Etch (stable): 3.81-2
Debian Sarge (old stable): 3.80-9
Debian unstable: 3.81-3

latest CVS builds fine on Etch, and it did work fine on Sarge last time I
tried. I can try again on Sarge with the latest CVS if it helps, let me know.

Just to make sure, the simplest way to check is after a successful make, run make again and see if everything recompiles.

I asked about versions, but forgot to ask if others had the problem on systems with make 3.80. I wonder if it really is just an OSX make glitch.

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

"Those people who most want to rule people are, ipso-facto, those least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy

18

Hi,

I notice with the latest CVS that "g.module.tmp.html" files are left in each
module directory after a build.

?
Hamish

____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting

19

Hi,

if there are no objections I will rename r.cats to be r.category (to match
v.category), leaving a r.cats symlink for backwards compatibility for the
duration of GRASS 6.x.

In addition I mean to move/copy the copy cats from raster= option from
r.support to r.category and add a rules= option to import category labels from
a file.
(r.support raster= is not in 6.2.x so no crime to move it, although if someone
cares we can copy it with a note that it will be removed for GRASS 7; or maybe
r.suppport is a better place for these things, not r.cats? but r.support is
already crowded)

I am unsure if it is better for the import format to match the current r.cats
output format, or to try and follow what r.reclass has. For FP maps we will
have to accept "a thru b<FS>Label" as well as "a<FS>Label" input rules. (<FS>
comes from the fs= option)

Note the category labels can be matched to FP ranges, see the nice writeup in
the GRASS 5.0 programmers' manual section 5.4. (I expect in the 6 prog manual
too but I don't have that on hand right now)

ideas welcome,
Hamish

____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/

20

Hamish wrote:

In addition I mean to move/copy the copy cats from raster= option from
r.support to r.category and add a rules= option to import category labels
from a file.

I forgot to mention that I'll make it easier to use dynamic labels too.
(currently there and working*, but somewhat hidden)

[*] but not for ps.map yet, see RT bug report #2437
     http://intevation.de/rt/webrt?serial_num=2437

Hamish

      ____________________________________________________________________________________
Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7