~olbohlen/oi-userland.git

			@@ -14,7 +14,16 @@
			field of `sha256sum $(COMPONENT_ARCHIVE)`.
			* COMPONENT_ARCHIVE_URL is where the archive can be downloaded from. This is
			typically constructed from $(COMPONENT_PROJECT_URL) and $(COMPONENT_ARCHIVE).
			* COMPONENT_BUGDB is the lower-case rendering of the BugDB cat/subcat.
			* COMPONENT_SIG_URL is the URL where the PGP signature for $(COMPONENT_ARCHIVE)
			can be found. This can be used in addition to the hash in
			$(COMPONENT_ARCHIVE_HASH) to verify the correctness of the archive. If
			COMPONENT_SIG_URL is present, then COMPONENT_ARCHIVE_HASH needn't be, but its
			presence is strongly encouraged to ensure that the archive contents don't
			change silently. Note that when merging, because
			$WS/tools/.gnupg/pubring.gpg is a binary file, you will have to choose
			the correct version. To check if key is imported, run:
			gpg2 --homedir=$(git rev-parse --show-toplevel)/tools/.gnupg --list-keys
			before you 'git commit' your merge.

			These two are both initialized in make-rules/shared-macros.mk rather than any
			component-level Makefile, but are frequently referenced from the latter.
			@@ -103,10 +112,15 @@
			* CONFIGURE_SCRIPT should be set if the default "$(SOURCE_DIR)/configure" is
			unsuitable for whatever reason.

			* studio_OPT has a default value of "-xO4". Occasional bugs in the optimizer
			have been found which have required altering this to "-xO3". There are also
			studio_OPT.$(MACH).$(BITS) versions of this available if greater specificity
			is needed.
			* gcc_OPT has a default value of "-O3". Occasional bugs in the optimizer
			have been found which have required altering this to "-O2" or lower values.
			There are also gcc_OPT.$(MACH).$(BITS) versions of this available if
			greater specificity is needed.

			* Variable PYTHON3_SOABI selects between two library naming schemes of
			python3 extensions: .cpython3Xm.so ("cpython") or .abi3.so ("abi3").
			Currently, only a few components use ABI3 compliant extensions,
			therefore, the default value is set to "cpython".

			If you frequently rebuild the same code, such as when you maintain a build server
			or iterate recipes for the same component, you can benefit by caching the build
			@@ -135,6 +149,13 @@
			and/or use `export CCACHE_LOGFILE=/tmp/ccache.log` to trace its activities.
			* You can dedicate a cache directory different from the default `$HOME/.ccache`
			for example with `export CCACHE_DIR=/tmp/ccache-dir; mkdir -p $CCACHE_DIR`.
			* Note: be wary of ccache's own CCACHE_DISABLE environment variable: any
			value (empty, "false" etc.) is considered a "true" setting for ccache
			booleans (and so CCACHE_DISABLE=false still disables the program, falling
			through to real compiler). This is according to the project's documentation
			and legacy (backwards compatibility), thus not accepted by upstream as a bug.
			To negate ccache boolean environment variable settings you can use their
			CCACHE_NO* counterparts, e.g. `export CCACHE_NODISABLE=anything`.
			* Troubleshooting: If no files appear in the cache, verify permissions and disk
			space. Also enable the log file and/or inspect configuration with `ccache -p`
			(see above) to see details about wrapped compilations. In particular,
			@@ -145,6 +166,8 @@
			running `gcc -o binprog *.c`).
			* You can inspect caching statistics with `ccache -s` and wipe the cache with
			`ccache -C -z`.
			* For debugging or development of the ccache component itself, you can use a
			custom build for oi-userland compilation with `export CCACHE=/path/to/ccache`
			* The cache directory can contain a configuration file for "ccache" program,
			which is the recommended way to provide tweaks to your setup. While exported
			environment variables (e.g. from shell profile) may work, our Makefiles do