This adds GLUON_BUILDTYPE, which is an option that allows specifying an alternate
base configuration
Other additions:
- GLUON_PREFIX option to specify the filename prefix, if
VERSION_DIST is set
- Skip gluon target-definitions if TARGET_ALL_PROFILES is set
- Allow overriding any file in targets/ by adding the file to site/
- Allow loading the original file using include_gluon() from gluon
Device-specific package additions could generate `CONFIG_PACKAGE_...=m`
lines, which would override `CONFIG_PACKAGE_...=y` lines inserted by
OpenWrt for default packages (as Gluon did not know about these default
packages). This resulted in the unintended removal of such packages from
other devices that did not contain the same package in their device
package lists.
Avoid this issue by explicitly adding OpenWrt's target default package
list to the front of Gluon's target package list.
We currently don't have any deprecated devices, so it doesn't make much
sense to force every site to specify this variable. Make it default to 0
instead.
Using `make container` or, if you don't have automake/gmake on your host
system, `./scripts/container.sh` will build an image for the current
branch your are on and drop you into a shell running inside a container
using that image.
From there all tooling required to work on Gluon is available.
Supports both podman (preferred) and docker.
The site.mk target was only evaluated after the whole makefile was
parsed. This caused the GLUON_DEPRECATED error to be emitted first
(hiding the more helpful message that no site config was found) on Gluon
2021.1.x, where GLUON_DEPRECATED is used in a toplevel if in targets.mk.
By moving the check from recipe context to the toplevel, we ensure that
it is evaluated during parsing.
Forgetting to `make update` or leaving uncommitted changes in the
repositories managed by Gluon is a recurring cause of confusion, even
for experienced developers. Let's print an obvious warning message in
this case.
This change stores a Kernel with Debug-Symbols for the current
architecture in a new output directory '<outputdir>/debug'.
This allows a developer or operator of a network to store the kernel
along with the actual images. In case of a kernel oops the debug
information can be used with the script
'scripts/decode_stacktrace.sh' in the kernel source tree to get the
names to the symbols of the stack trace.
OpenWRT already provides the CONFIG_COLLECT_KERNEL_DEBUG -option that
creates a kernel with debug-symbols in the OpenWRT output directory.
This change enables this option and copies the generated kernel to the
gluon output directory.
Signed-off-by: Chrissi^ <chris@tinyhost.de>
This reverts commit 2a8943e516.
.SILENT gets passed down to OpenWrt make as -s through MAKEFLAGS. This
hides certain messages from the build log with V=s.
The precedence of different package lists was broken since #1876,
disallowing removal of GLUON_FEATURES packages via GLUON_SITE_PACKAGES.
Including all package selections, both implicit defaults and explicit
handling in Gluon, the order of precedence is now the following:
1. OpenWrt defaults (including target-specific defaults)
2. Device-specific packages from OpenWrt
3. Generic default packages (from target/generic)
4. Target default packages (target/$(GLUON_TARGET))
5. Removal of opkg for tiny targets
6. Packages derived from GLUON_FEATURES + GLUON_FEATURES_$(class)
7. GLUON_SITE_PACKAGES
8. GLUON_SITE_PACKAGES_$(class)
9. Device-specific packages from target/$(GLUON_TARGET)
10. Device-specific packages from GLUON_$(device)_SITE_PACKAGES
This also contains various pieces of cleanup:
- No hardcoded order of device classes for target_config.lua arguments
anymore (in fact, the Makefile doesn't know anything about device
classes now)
- target_conifg_lib.lua only hardcodes the fallback class for x86, no
other occurences of specific class names
- Feature -> package list mapping is moved from Makefile to the Lua code
as well (still implemented in Shell though)
Instead of exporting various variables (unintendedly making them
available to the OpenWrt build, possibly bypassing .config), pass the
environment only to commands that need it.
By using .ONESHELL and adding -e to .SHELLFLAGS, we can simplify complex
shell commands (like manifest generation) and gain a simple way to pass
multi-line environment variables into shell commands.
The @ and + flags for recipe commands are moved to the top of each
recipe.
This commit allows to define a device-class flag in the target
definitions. This way, it is possible to distinguish between groups
of devices in the build-process in terms of package or feature
selection.
This new build flag is mandatory for now (it may default to 0 in a future
Gluon version). It may be set to the following values:
* 0 - Do not build any images for deprecated devices.
* upgrade - Only build sysupgrade images for deprecated devices.
* full - Build both sysupgrade and factory images for deprecated devices.
"Other" images are handled like factory images, as they are also used for
the initial installation of Gluon on a device.
By passing the package name through merge_packages, it becomes possible to
override the package choice in GLUON_SITE_PACKAGES again, for example:
GLUON_SITE_PACKAGES += -hostapd-mini hostapd
Allow using relative paths for GLUON_SITEDIR, GLUON_OUTPUTDIR, ...
We also check for whitespace in paths now, as build will not work properly
with whitespace anyways, and Make's abspath would require escaping
otherwise.
[Matthias Schiffer: minor changes, rewrite commit message]
To reduce the number of packages that need to be listed in
GLUON_SITE_PACKAGES, this adds a new variable GLUON_FEATURES. Sets of
packages are enabled automatically based on the combination of listed
feature flags.
Site-specified package feeds can provide their own feature flag
definitions.
