Usually gluon calls "git describe" inside the gluon directory to determine
the gluon-version. While this is sufficient in most cases, it becomes
insufficient if you have a meta build system, which patches gluon before
building gluon.
It is actually insufficient, because if you patch gluon before building
it, the the output of "git describe" would then describe the patched
revision and not the base revision (before patching gluon).
After this commit, you can use .scmversion to avoid this problem. By
writing to .scmversion inside the gluon directory before calling make,
gluon will now use the contents of .scmversion instead of "git describe"
to define the gluon-version. So you can write to .scmversion to define
gluon-version before patching gluon in your meta build system.
To do this, you can do something like this in your meta build system:
cd gluon
make show-describe > .scmversion
# apply your own patches to gluon
git am < ...
# make gluon
make GLUON_TARGET=...
Instead of using the output of "make show-describe" as .scmversion, you
can also use any other useful version description. E.g. you may append
the number of additional patches on top of the base commit of gluon (or
so).
As a side note, inside gluon, you can obtain the version (as before) via:
root@platzhalter-525400123457:/# cat /lib/gluon/gluon-version
v2021.1-150-gb39ea759+
root@platzhalter-525400123457:/# gluon-neighbour-info -r nodeinfo
{
...
"software": {
"firmware": {
"base": "gluon-v2021.1-150-gb39ea759+",
...
}
}
}
root@platzhalter-525400123457:/# opkg info gluon-core | grep ^Version:
Version: v2021.1-150-gb39ea759+
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.
