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

[Markus Neteler]

On Wed, Feb 11, 2004 at 07:06:59PM +0000, Glynn Clements wrote:
> 
> 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. 

The "make copymix" is not the standard procedure. With
"make mix" such problems do not happen.

> I was concerned that people might use "make copymix" without realising that
> they will have to do "rm -rf ... ; cvs checkout ..." to update it.

Maybe we should add a remark to INSTALL.
 
> > 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.

Up to now I/we have eliminated all cases like that.

The time to identify the problem and response time to suggest a solution 
was a fraction of a day (took me 2 seconds to understand the problem,
I didn't see the mail earlier).
IMHO this is not a severe problem, there are other problems which are much
more important.
And it happened the first time for month.

> This only needs to happen
> once in order to create substantially more work than it saves.

Once we have a solution for the problem asked by Radim it
might be solved in a more general way. But this solution we don't
have yet, so we still have to separate into directories...

Markus