Documentation: Update Makefile .inc references to .mk

Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I464170e60a22f39225044c6794d091455d931e9c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80128
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This commit is contained in:
Martin Roth 2024-01-18 19:32:02 -07:00 committed by Felix Singer
parent d0096c11b2
commit e3a3cc1009
5 changed files with 13 additions and 13 deletions

View file

@ -7,10 +7,10 @@ to the point of providing its own custom language.
The overhead of learning this new syntax is (hopefully) offset by its lower The overhead of learning this new syntax is (hopefully) offset by its lower
complexity. complexity.
The build system is defined in the toplevel `Makefile` and `toolchain.inc` The build system is defined in the toplevel `Makefile` and `toolchain.mk`
and is supposed to be generic (and is in fact used with a number of other and is supposed to be generic (and is in fact used with a number of other
projects). Project specific configuration should reside in files called projects). Project specific configuration should reside in files called
`Makefile.inc`. `Makefile.mk`.
In general, the build system provides a number of "classes" that describe In general, the build system provides a number of "classes" that describe
various parts of the build. These cover the various build targets in coreboot various parts of the build. These cover the various build targets in coreboot
@ -36,7 +36,7 @@ TODO: explain how to create new classes and how to evaluate them.
### subdirs ### subdirs
`subdirs` contains subdirectories (relative to the current directory) that `subdirs` contains subdirectories (relative to the current directory) that
should also be handled by the build system. The build system expects these should also be handled by the build system. The build system expects these
directories to contain a file called `Makefile.inc`. directories to contain a file called `Makefile.mk`.
Subdirectories are not read at the point where the `subdirs` statement Subdirectories are not read at the point where the `subdirs` statement
resides but later, after the current directory is handled (and potentially resides but later, after the current directory is handled (and potentially
@ -66,7 +66,7 @@ supported options are:
You can use the `add_intermediate` helper to add new post-processing steps for You can use the `add_intermediate` helper to add new post-processing steps for
the final `coreboot.rom` image. For example you can add new files to CBFS by the final `coreboot.rom` image. For example you can add new files to CBFS by
adding something like this to `site-local/Makefile.inc` adding something like this to `site-local/Makefile.mk`
``` ```
$(call add_intermediate, add_mrc_data) $(call add_intermediate, add_mrc_data)
@ -100,4 +100,4 @@ The default implementation just returns `COREBOOT` (the default region) for
all files. all files.
vboot provides its own implementation of `regions-for-file` that can be used vboot provides its own implementation of `regions-for-file` that can be used
as reference in `src/vboot/Makefile.inc`. as reference in `src/vboot/Makefile.mk`.

View file

@ -963,7 +963,7 @@ variable. This is not set in coreboot, which uses the default CONFIG_ prefix
for all of its symbols. for all of its symbols.
The coreboot makefile forces the config.h file to be included into all coreboot The coreboot makefile forces the config.h file to be included into all coreboot
C files. This is done in Makefile.inc on the compiler command line using the C files. This is done in Makefile.mk on the compiler command line using the
“-include $(obj)/config.h” command line option. “-include $(obj)/config.h” command line option.
Example of various symbol types in the config.h file: Example of various symbol types in the config.h file:

View file

@ -114,7 +114,7 @@ defconfig pointing to your [software-name] generated File.
as part of your software's build process. For example in form of a as part of your software's build process. For example in form of a
Makefile target. Makefile target.
2. Change src/sbom/Makefile.inc (in order to know where to find the 2. Change src/sbom/Makefile.mk (in order to know where to find the
CoSWID/SWID/uSWID file) as well as the Makefile in coreboot which CoSWID/SWID/uSWID file) as well as the Makefile in coreboot which
builds said software. For example for GRUB2 that could mean to add a builds said software. For example for GRUB2 that could mean to add a
Makefile target in payloads/external/GRUB2/Makefile. Makefile target in payloads/external/GRUB2/Makefile.

View file

@ -247,13 +247,13 @@ tests/lib/string-test and tests/device/i2c-test:
│ ├── include │ ├── include
│ │ ├── mocks <- mock headers, which replace original headers │ │ ├── mocks <- mock headers, which replace original headers
│ │ │ │
│ ├── Makefile.inc <- top Makefile for unit tests subsystem │ ├── Makefile.mk <- top Makefile for unit tests subsystem
│ ├── lib │ ├── lib
│ │ ├── Makefile.inc │ │ ├── Makefile.mk
│ │ ├── string-test.c <- test code for src/lib/string.c │ │ ├── string-test.c <- test code for src/lib/string.c
│ │ │ │ │ │
│ ├── device │ ├── device
│ │ ├── Makefile.inc │ │ ├── Makefile.mk
│ ├── i2c-test.c │ ├── i2c-test.c
├── build ├── build

View file

@ -96,8 +96,8 @@ suffix `-test` to the UUT name when creating a new test harness file.
be registered with the coreboot unit testing infrastructure. be registered with the coreboot unit testing infrastructure.
``` ```
Every directory under `tests/` should contain a Makefile.inc, similar to Every directory under `tests/` should contain a Makefile.mk, similar to
what can be seen under the `src/`. Register a new test in Makefile.inc, what can be seen under the `src/`. Register a new test in Makefile.mk,
by __appending__ test name to the `tests-y` variable. by __appending__ test name to the `tests-y` variable.
```eval_rst ```eval_rst
@ -285,7 +285,7 @@ stimulate UUT as required without changing the source code.
coreboot unit test infrastructure supports overriding of functions at coreboot unit test infrastructure supports overriding of functions at
link time. This is as simple as adding a `name_of_function` to be link time. This is as simple as adding a `name_of_function` to be
mocked into <test_name>-mocks variable in Makefile.inc. The result is mocked into <test_name>-mocks variable in Makefile.mk. The result is
that the test's implementation of that function is called instead of that the test's implementation of that function is called instead of
coreboot's. coreboot's.