Re: Hierarchical building

[Kaz Kylheku (gmake)]

On 2021-12-02 09:12, Ian Molton wrote:
> indeed, I'm finding it hard to understand the placement of anything in 
> a
> makefile - they seem to be processed from top to bottom, but "not
> always", and its not obvious how.

Makefiles are programs. Like C, Javascript, Fortran or Shell,
they are generally read from top to bottom, but the execution of
the contents doesn't follow that path.

The make language is declarative. Certain effects can be relied
upon to occur at read time, like the establishment of variable values.
The main abstraction is the rule, which declares that some
targets depend on prerequisites, and specifies the update recipe.

The rules execute in dependency order, not in order of appearance,
and unnecessary rules are skipped.

A rule cannot directly invoke another one like a function,
though by manipulating the dependencies, you can get things to
happen in certain required orders.

> I'd also like to know if there's a reliable way to disable all the
> "build in" rules and variables, so that I have no risk of "tripping
> over" them - I've found -r and -R, but I've also found dire warnings in
> (eg. Linux) that this isn't reliable in all versions of make.

Built-in rules can be disabled using a .SUFFIXES: pseudo-target with
no prerequisites:

  .SUFFIXES:

The built-in rules are tied to file suffixes (they are defined as if
using classic suffix rules such as .c.o:) and this empty .SUFFIXES:
has the effect of deleting the rules.

I think .SUFFIXES: is an example of a top-to-bottom construct.
Though it uses rule syntax, I think its side effect upon the list
of suffixes and built-in rules occurs as it is being read.

It has to be, because a suffix rule has to be preceded by a .SUFFIXES
which declares the suffixes used in that rule.