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

GRASS GRASS developer
1

On Wednesday 11 February 2004 11:05, you 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. 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.

> 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). The problem is to create more modules using
one rule. It is possible to specify (at least GNU make) target specific variables:

default: cmd1 cmd2

cmd1: CMD_OBJS = maina.o
cmd1: PGM = testa
cmd1: cmd

cmd2 : PGM = testb
cmd2 : CMD_OBJ =mainb.o
cmd2 : cmd

but I don't know how to change this:

cmd: bincmd

ARCH_CMD_OBJS := $(foreach obj,$(CMD_OBJS),OBJ.$(ARCH)/$(obj))

bincmd: $(ARCH_INTER_OBJS) $(DEPENDENCIES)
        $(CC) $(LDFLAGS) $(XTRA_LDFLAGS) -o $@ $(ARCH_INTER_OBJS) $(LIBES) $(MATHLIB) $(XDRLIB)

to create properly list of objects and objects.

Radim

2

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@virgin.net>

3

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