On Sun, Jan 8, 2023 at 1:37 PM Thibaut <[email protected]> wrote: > > Le 8 janv. 2023 à 21:53, Christian Marangi <[email protected]> a écrit : > > > > On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote: > >> Brian Norris <[email protected]> [2023-01-06 23:49:44]: > >> > >> Hi Brian, > >> > >>> I need to express a per-target dependency on the 'base64' utility, and > >>> that's seemingly impossible to do for busybox. > >> > >> --- a/target/linux/ipq806x/Makefile > >> +++ b/target/linux/ipq806x/Makefile > >> @@ -15,6 +15,11 @@ KERNEL_PATCHVER:=5.15 > >> KERNELNAME:=zImage Image dtbs > >> > >> include $(INCLUDE_DIR)/target.mk > >> + > >> +DEPENDS:= \ > >> + +@BUSYBOX_DEFAULT_BASE64 > >> +
Thanks! That does indeed work for me. And I might just throw it into target/linux/ipq806x/chromium/target.mk instead, since the generic target won't be using base64. > > Is this already used for other target? Wonder if this special thing > > would cause some problem for packages of this target? Like discrepancy > > with stage2 and final image? stage2 as in sysupgrade? I don't immediately see how that would be a problem, but maybe I'm not understanding well enough. > AFAICT this isn’t used anywhere so far (at least according to a quick git > grep). Right, I couldn't find any other target tweaking BUSYBOX_DEFAULT_* in the current tree or in the git history. And I can't even find anyone doing a bare 'DEPENDS:=' in their Makefile under target/linux/ at all. All usages are as part of packages (modules), not device/target specifications. > > Anyway this looks to be the best solution for the problem. > > I wonder if it’s such a good idea to have discrepancies in busybox features > between targets? I don't think I know enough about OpenWrt development yet to have a good answer on this, so I'll let you all try to answer this. But if I don't hear some specific negatives or some other consensus within a day or few, I'll try BUSYBOX_DEFAULT_BASE64 for a v3. Of course, I can also hold off sending if people were actively looking at the other parts of this series still. Brian _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
