[GRASS-dev] installed makefile cleanup

[Glynn Clements]

William Kyngesburye wrote:

> >> I sortof understand this.  Until you can work out the necessary
> >> changes (if you decide to), how about some minimal changes to the the
> >> extension compilation working?
> >
> > Unfortunately, use of the "get it working for now" approach is
> > responsible for much of the current mess. I'd rather take the
> > opportunity to improve matters than to make them worse.
> 
> OK.  I guess I'm just being a bit impatient.
> 
> So, you're working on this now? ;)  Or will get to it?

The latter. I have "Makefile fatigue" right now, and I want to allow
people to find any bugs in the most recent bunch of changes.

> >> - grass.make.in: add at end:
> >>
> >> ifdef INST_XTN
> >> include $(MODULE_TOPDIR)/include/Make/Install_xtn.make
> >> endif
> >>
> >> and have a new Install_xtn.make fragment.  This is just a trimmed
> >> version of the main makefile with just install targets and any
> >> unnecessary bits removed.  It expects INST_DIR_XTN to be set in the
> >> make command.
> >
> > I'm not sure that this needs to be conditionalised. If there are parts
> > of the top-level Makefile which might be useful to extensions, they
> > should be moved into one of the *.make files (or a new file).
> >
> > In general, the *.make files should define as much as possible
> > unconditionally, and leave it up to either individual Makefiles or the
> > user to decide what actually gets used.
> 
> Just to make sure: the main makefile's install target will override  
> that makefile frag's install target, in a normal build, since the  
> main makefile defines it after this frag is included?

GRASS' top-level Makefile only includes Grass.make and Platform.make. 
It doesn't include any of the other *.make fragments.

In general, try to avoid relying upon overriding rules which are
defined in the *.make files. Sometimes, overriding rules is
unavoidable (e.g. some modules which don't understand
--html-description have to override the htmletc target), but it's best
not to rely upon it.

Apart from printing a warning (which adds "noise" to the build
output), if the two versions have both dependencies and commands, the
dependencies get merged (sometimes in ways which make the value of $<
etc unpredictable) but the commands get overridden.

Also, whenever the generic rule is updated, you often end up having to
manually update any local versions.

[E.g. I've just extended the "clean" rule to allow a list of
subdirectories to be specified as CLEAN_SUBDIRS. Previously,
r.terraflow, r.le.setup and v.clean were overriding the clean target
to handle subdirectories, which meant that they weren't deleting the
$(PGM).tmp.html file.]

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