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

Glynn Clements glynn at gclements.plus.com
Tue Oct 2 13:30:27 EDT 2007


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 at gclements.plus.com>




More information about the grass-dev mailing list