[GRASS5] Re: [GRASSLIST:2557] Re: build errors on r.le

[Glynn Clements]

Radim Blazek wrote:

> > > > There is no other way as following these rules:
> > > >
> > > > cd /where/your/grass530/lives/
> > > > cvs update -dP
> > > >
> > > > cd /where/your/grass57/lives/
> > > > make mixclean
> > > > #here verify, that grass57/raster/r.le/r.le.setup/polytocell/ does
> > > > # not contain any links to 5.3 (the file bmf_to_cll.c should not be
> > > > there # any more which is causing the problem on your computer).
> > >
> > > AFAICT, "make copymix" will fall down in this situation; perhaps that
> > > option should be removed?
> 
> Which situation exactly? After 'make mixclean'? 'copymix' is intended
> to be run once to create complete source code, which cannot be later 
> updated of course.

I guess that my point was essentially that the inability to
subsequently update the source isn't particularly obvious. I was
concerned that people might use "make copymix" without realising that
they will have to do "rm -rf ... ; cvs checkout ..." to update it.

> And I prefer to keep this target, because to install
> full 5.0 source if I want to compile 5.7 on iPaq, is realy impractical.

If there's a legitimate use for it, fair enough.

> > > Also, this is one of the reasons why using tricks like:
> > >
> > > 	OBJS = $(subst .c,.o,$(wildcard *.c))
> > >
> > > is generally considered to be a bad idea.
> 
> This simplifies Makefiles of most modules and libs, I don't see 
> as a problem to create list of objects authomaticaly if it is
> possible (and in 95% it is).

It isn't a problem if everything goes according to plan. However, if
any extraneous source files exist in a directory (and there are a
number of ways that this can happen), it can result in problems which
can be particularly awkward to identify. This only needs to happen
once in order to create substantially more work than it saves.

-- 
Glynn Clements <glynn.clements at virgin.net>