diff options
| -rw-r--r-- | Documentation/getting_started/build_system.md | 10 | ||||
| -rw-r--r-- | Documentation/getting_started/kconfig.md | 2 | ||||
| -rw-r--r-- | Documentation/sbom/sbom.md | 2 | ||||
| -rw-r--r-- | Documentation/technotes/2020-03-unit-testing-coreboot.md | 6 | ||||
| -rw-r--r-- | Documentation/tutorial/part3.md | 6 |
5 files changed, 13 insertions, 13 deletions
diff --git a/Documentation/getting_started/build_system.md b/Documentation/getting_started/build_system.md index 4013bc6057..35ed187989 100644 --- a/Documentation/getting_started/build_system.md +++ b/Documentation/getting_started/build_system.md @@ -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 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 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 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` contains subdirectories (relative to the current directory) that 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 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 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) @@ -100,4 +100,4 @@ The default implementation just returns `COREBOOT` (the default region) for all files. 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`. diff --git a/Documentation/getting_started/kconfig.md b/Documentation/getting_started/kconfig.md index d40a4cc1ec..ddd32762a9 100644 --- a/Documentation/getting_started/kconfig.md +++ b/Documentation/getting_started/kconfig.md @@ -963,7 +963,7 @@ variable. This is not set in coreboot, which uses the default CONFIG_ prefix for all of its symbols. 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. Example of various symbol types in the config.h file: diff --git a/Documentation/sbom/sbom.md b/Documentation/sbom/sbom.md index c4984f971b..654fe5565e 100644 --- a/Documentation/sbom/sbom.md +++ b/Documentation/sbom/sbom.md @@ -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 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 builds said software. For example for GRUB2 that could mean to add a Makefile target in payloads/external/GRUB2/Makefile. diff --git a/Documentation/technotes/2020-03-unit-testing-coreboot.md b/Documentation/technotes/2020-03-unit-testing-coreboot.md index a4d283f693..d95b1a00db 100644 --- a/Documentation/technotes/2020-03-unit-testing-coreboot.md +++ b/Documentation/technotes/2020-03-unit-testing-coreboot.md @@ -247,13 +247,13 @@ tests/lib/string-test and tests/device/i2c-test: │ ├── include │ │ ├── mocks <- mock headers, which replace original headers │ │ -│ ├── Makefile.inc <- top Makefile for unit tests subsystem +│ ├── Makefile.mk <- top Makefile for unit tests subsystem │ ├── lib -│ │ ├── Makefile.inc +│ │ ├── Makefile.mk │ │ ├── string-test.c <- test code for src/lib/string.c │ │ │ │ ├── device -│ │ ├── Makefile.inc +│ │ ├── Makefile.mk │ ├── i2c-test.c │ ├── build diff --git a/Documentation/tutorial/part3.md b/Documentation/tutorial/part3.md index 39d6ed5788..ec49637e29 100644 --- a/Documentation/tutorial/part3.md +++ b/Documentation/tutorial/part3.md @@ -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. ``` -Every directory under `tests/` should contain a Makefile.inc, similar to -what can be seen under the `src/`. Register a new test in Makefile.inc, +Every directory under `tests/` should contain a Makefile.mk, similar to +what can be seen under the `src/`. Register a new test in Makefile.mk, by __appending__ test name to the `tests-y` variable. ```eval_rst @@ -285,7 +285,7 @@ stimulate UUT as required without changing the source code. coreboot unit test infrastructure supports overriding of functions at 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 coreboot's. |