... | @@ -69,16 +69,15 @@ sections: |
... | @@ -69,16 +69,15 @@ sections: |
|
As its name suggests, `boilerplate.mk`
|
|
As its name suggests, `boilerplate.mk`
|
|
consists of a large quantity of standard
|
|
consists of a large quantity of standard
|
|
`Makefile` code. We discuss this
|
|
`Makefile` code. We discuss this
|
|
boilerplate in more detail in \<xref linkend="sec-boiler"/\>.
|
|
boilerplate in more detail in [The {{{mk/boilerplate.mk}}} file](#The{{{mk/boilerplate.mk}}}file).
|
|
|
|
|
|
> >
|
|
Before the `include` statement, you
|
|
> > Before the `include` statement, you
|
|
must define the `make` variable
|
|
> > must define the `make` variable
|
|
`TOP`
|
|
> > `TOP`
|
|
to be the top-level directory of the source tree, containing
|
|
> > to be the top-level directory of the source tree, containing
|
|
the `mk`
|
|
> > the `mk`
|
|
directory in which the `boilerplate.mk`
|
|
> > directory in which the `boilerplate.mk`
|
|
file is. It is *not* OK to simply say
|
|
> > file is. It is *not* OK to simply say
|
|
|
|
|
|
|
|
```wiki
|
|
```wiki
|
|
include ../mk/boilerplate.mk # NO NO NO
|
|
include ../mk/boilerplate.mk # NO NO NO
|
... | @@ -239,35 +238,33 @@ SRC_HC_OPTS += -O |
... | @@ -239,35 +238,33 @@ SRC_HC_OPTS += -O |
|
`target.mk` has a rule that looks
|
|
`target.mk` has a rule that looks
|
|
like this:
|
|
like this:
|
|
|
|
|
|
```wiki
|
|
```wiki
|
|
$(HS_PROG) : $(OBJS)
|
|
$(HS_PROG) : $(OBJS)
|
|
$(HC) $(LD_OPTS) $< -o $@
|
|
$(HC) $(LD_OPTS) $< -o $@
|
|
```
|
|
```
|
|
|
|
|
|
> >
|
|
If this rule was in
|
|
> > If this rule was in
|
|
`boilerplate.mk` then
|
|
> > `boilerplate.mk` then
|
|
`$(HS_PROG)`
|
|
> > `$(HS_PROG)`
|
|
and
|
|
> > and
|
|
`$(OBJS)`
|
|
> > `$(OBJS)`
|
|
would not have their final values at the moment
|
|
> > would not have their final values at the moment
|
|
`make` encountered the rule. Alas,
|
|
> > `make` encountered the rule. Alas,
|
|
`make` takes a snapshot of their
|
|
> > `make` takes a snapshot of their
|
|
current values, and wires that snapshot into the rule.
|
|
> > current values, and wires that snapshot into the rule.
|
|
(In contrast, the commands executed when the rule
|
|
> > (In contrast, the commands executed when the rule
|
|
"fires" are only substituted at the moment
|
|
> > "fires" are only substituted at the moment
|
|
of firing.) So, the rule must follow the definitions
|
|
> > of firing.) So, the rule must follow the definitions
|
|
given in the `Makefile` itself.
|
|
> > given in the `Makefile` itself.
|
|
- Unlike pattern rules, ordinary rules cannot be
|
|
|
|
overriden or replaced by subsequent rules for the same
|
|
- Unlike pattern rules, ordinary rules cannot be
|
|
target (at least, not without an error message).
|
|
overriden or replaced by subsequent rules for the same
|
|
Including ordinary rules in
|
|
target (at least, not without an error message).
|
|
`boilerplate.mk` would prevent the
|
|
Including ordinary rules in
|
|
user from writing rules for specific targets in specific
|
|
`boilerplate.mk` would prevent the
|
|
cases.
|
|
user from writing rules for specific targets in specific
|
|
- There are a couple of other reasons I've
|
|
cases.
|
|
forgotten, but it doesn't matter too much.
|
|
- There are a couple of other reasons I've
|
|
|
|
forgotten, but it doesn't matter too much.
|
|
|
|
|
|
|
|
## The `mk/boilerplate.mk` file
|
|
## The `mk/boilerplate.mk` file
|
|
|
|
|
... | @@ -490,7 +487,7 @@ Here's how to understand the rule. It says that |
... | @@ -490,7 +487,7 @@ Here's how to understand the rule. It says that |
|
name held in `$(CC)`), passing to it
|
|
name held in `$(CC)`), passing to it
|
|
the options `$(CC_OPTS)` and
|
|
the options `$(CC_OPTS)` and
|
|
the rule's dependent file of the rule
|
|
the rule's dependent file of the rule
|
|
`$<` (`Foo.c` in
|
|
`$<` (`Foo.c` in
|
|
this case), and putting the result in the rule's target
|
|
this case), and putting the result in the rule's target
|
|
`$@` (`Foo.o` in this
|
|
`$@` (`Foo.o` in this
|
|
case).
|
|
case).
|
... | @@ -523,9 +520,9 @@ meaning: |
... | @@ -523,9 +520,9 @@ meaning: |
|
- `SRC_CC_OPTS`:
|
|
- `SRC_CC_OPTS`:
|
|
options passed to all C compilations.
|
|
options passed to all C compilations.
|
|
|
|
|
|
- `WAY_<way>_CC_OPTS`:
|
|
- `WAY_<way>_CC_OPTS`:
|
|
options passed to C compilations for way
|
|
options passed to C compilations for way
|
|
`<way>`. For example,
|
|
`<way>`. For example,
|
|
`WAY_mp_CC_OPTS`
|
|
`WAY_mp_CC_OPTS`
|
|
gives options to pass to the C compiler when compiling way
|
|
gives options to pass to the C compiler when compiling way
|
|
`mp`. The variable
|
|
`mp`. The variable
|
... | @@ -534,9 +531,9 @@ meaning: |
... | @@ -534,9 +531,9 @@ meaning: |
|
standard way. (\<xref linkend="sec-ways"/\> dicusses
|
|
standard way. (\<xref linkend="sec-ways"/\> dicusses
|
|
multi-way compilation.)
|
|
multi-way compilation.)
|
|
|
|
|
|
- `<module>_CC_OPTS`:
|
|
- `<module>_CC_OPTS`:
|
|
options to pass to the C compiler that are specific
|
|
options to pass to the C compiler that are specific
|
|
to module `<module>`. For example,
|
|
to module `<module>`. For example,
|
|
`SMap_CC_OPTS` gives the
|
|
`SMap_CC_OPTS` gives the
|
|
specific options to pass to the C compiler when compiling
|
|
specific options to pass to the C compiler when compiling
|
|
`SMap.c`.
|
|
`SMap.c`.
|
... | @@ -635,8 +632,7 @@ the sub-directories. |
... | @@ -635,8 +632,7 @@ the sub-directories. |
|
*These recursive invocations are guaranteed to
|
|
*These recursive invocations are guaranteed to
|
|
occur in the order in which the list of directories is specified
|
|
occur in the order in which the list of directories is specified
|
|
in `SUBDIRS`. *This guarantee can
|
|
in `SUBDIRS`. *This guarantee can
|
|
be important. For example, when you say {{{make
|
|
be important. For example, when you say `make boot` it can be important that the recursive invocation
|
|
boot}}} it can be important that the recursive invocation
|
|
|
|
of `make boot` is done in one sub-directory
|
|
of `make boot` is done in one sub-directory
|
|
(the include files, say) before another (the source files).
|
|
(the include files, say) before another (the source files).
|
|
Generally, put the most independent sub-directory first, and the
|
|
Generally, put the most independent sub-directory first, and the
|
... | | ... | |