- Dec 20, 2023
-
-
David Bauer authored
Create an init routine which loads the environment only once instead every evaluation. Signed-off-by:
David Bauer <mail@david-bauer.net>
-
- Dec 19, 2023
-
-
David Bauer authored
Include the file-extension with the image-customization.lua file. This will ease work with editors providing syntax highlighting, as they now properly detect the file-type. Signed-off-by:
David Bauer <mail@david-bauer.net>
-
David Bauer authored
Signed-off-by:
David Bauer <mail@david-bauer.net>
-
David Bauer authored
Signed-off-by:
David Bauer <mail@david-bauer.net>
-
David Bauer authored
-
David Bauer authored
Implement a flexible system for handling site-defined features as well as packages. This system is inspired by the existing feature-system and allows for a more flexible approach for selecting specific packages for devices. Features are now defined in a `features` file in the site-root. The same goes for packages. These files are sequentially evaluated and the device-package list is evaluated for each device independently. Signed-off-by:
David Bauer <mail@david-bauer.net>
-
- Aug 23, 2022
-
-
Matthias Schiffer authored
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.
-
Matthias Schiffer authored
OpenWrt's default package list contains the package "nftables", which is a virtual package provided by "nftables-json" and "nftables-nojson". Explicitly handle this case, otherwise our config check will fail when we extend our default package list with the one from OpenWrt.
-
Matthias Schiffer authored
Another leftover from legacy OpenWrt targets, which we don't support anymore.
-
- Mar 24, 2022
-
-
Matthias Schiffer authored
No legacy OpenWrt targets exist anymore which require the .config profile name to differ from the image name.
-
- Jul 13, 2021
-
-
Matthias Schiffer authored
With the removal of ramips-rt305x, all targets come with opkg again.
-
- Aug 28, 2020
-
-
Matthias Schiffer authored
All defined features need to be known at the same time, otherwise handling a feed-provided feature definition file would add gluon-web-advanced etc. to the package list when the corresponding feature flags appear in GLUON_FEATURES. Fixes: ee5ec5af ("build: rewrite features.sh in Lua")
-
- Jul 01, 2020
-
-
Matthias Schiffer authored
The `features` file is converted to a Lua-based DSL. A helper function `_` is used in the DSL; this will return the original string for enabled features, and nil for disabled features. This allows to use boolean operations on features without making the code too verbose. Besides having more readable and robust code, this also fixes the bug that all files `packages/*/features` were evaluated instead of only using the feature definitions of currently active feeds.
-
Matthias Schiffer authored
-
- Jun 12, 2020
-
-
Matthias Schiffer authored
Normally, we build all nonshared packages (which includes all kernel modules) to generate an opkg feed for later package installations by users. On targets without opkg, this just wastes time - disable it. (cherry picked from commit b3edfd29)
-
- Jun 11, 2020
-
-
Matthias Schiffer authored
Normally, we build all nonshared packages (which includes all kernel modules) to generate an opkg feed for later package installations by users. On targets without opkg, this just wastes time - disable it.
-
- May 31, 2020
-
-
Matthias Schiffer authored
target_config.lua and target_config_check.lua don't pass a table of callbacks anymore, so target_config_lib.lua can by simplified by moving all the code that was in the returned function to the toplevel.
-
Matthias Schiffer authored
So far, we were using a sort operation on the generated .config to implement precedence of =y packages over =m, and =m over unset. Unfortunately, this sort not only used for packages, but for all config lines. This made it impossible to override settings from targets/generic in a target config when the new setting was sorted before the generic setting. To fix this, track configurations by their keys, so we can properly override config keys that were set before. Value-based precedence is only preserved for package configuration. The config() and try_config() calls always take key and value as separate arguments now. Strings are quoted automatically; the values true, nil and false map to y, m and unset for tristate options. config() can take an optional third argument to override the error message to display when the setting fails to apply. All existing target configs generate the same .config with the old and the new code. The new code is also a bit faster on targets with many devices.
-
- May 03, 2020
-
-
Matthias Schiffer authored
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)
-
Matthias Schiffer authored
-
- Mar 27, 2020
-
-
David Bauer authored
When adding device classes, targets without devices such as x86 were not handled. As site and feature packages are included on such a per-device decision, x86 images ended up without most packages. Include a class setting for a target and include the class-packages target-wide when this setting is configured. Fixes 9c523650 ("build: introduce device classes")
-
- Mar 25, 2020
-
-
David Bauer authored
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.
-
- Sep 14, 2019
-
-
Matthias Schiffer authored
Fixes: 071cf7b2 ("Switch to Lua for target definitions")
-
- Jun 17, 2019
-
-
Matthias Schiffer authored
-