From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko =?ISO-8859-1?Q?St=FCbner?= Date: Sat, 25 Apr 2020 23:31:27 +0200 Subject: [Buildroot] [PATCH] boot/uboot: add option to define custom dependencies In-Reply-To: <20200425232245.6e13c5a6@windsurf.home> References: <20200425000629.2068191-1-heiko@sntech.de> <20200425211350.GR5035@scaer> <20200425232245.6e13c5a6@windsurf.home> Message-ID: <2530327.UWAnRXb5oC@diego> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Hi Thomas, Yann, Am Samstag, 25. April 2020, 23:22:45 CEST schrieb Thomas Petazzoni: > Hello, > > On Sat, 25 Apr 2020 23:13:50 +0200 > "Yann E. MORIN" wrote: > > > My opinion on that patch is that i am definitely not in favour of it. If > > we go that route, then we would have to allow adding any such arbitrary > > dependencies to a wide range of packages. > > Without necessarily strongly supporting Heiko's patch, I think it is > important to keep in mind that U-Boot is not a package like any others. > We offer version selection for U-Boot, custom Git/Subversion repo > selection, which we do not offer for other packages. U-Boot has > zillions of forks, support for gazillions platforms each with their own > funky requirements. > > We've already added a BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS to pass custom > make options, adding the possibility to add custom dependencies would > go in the same direction. > > I however agree that this kind of option is a good recipe for people to > do their own hacks on their side, instead of finding a proper way to do > it that can be upstreamed to Buildroot. > > > Now, there are two situations: > > > > - the tool is already in Buildroot: add a new _NEEDS_FOO option like > > we already have. > > > > - the tool is in a br2-external tre: this is in my opinion better > > served by working on the evaluation-postpone changes Arnou and I > > have been suggesting for quite a while now. > > I think it would make sense to hear about what Heiko's use case exactly > is, this might help. the use-case is: - a u-boot config fragment specifying key-dir and key-hint for signing uboot parts - see [0] - our own package managing these (and other) keys - and thus us wanting to make sure the key package gets "build" before u-boot itself I'm not overly attached to my patch, but it somehow felt in line with also the config-fragment option, that allows including other random fragments into the board config file for the u-boot build. So yes, the required package is in a br2-external tree. What is this "evaluation-postpone" thingy? Thanks Heiko [0] https://patchwork.ozlabs.org/project/uboot/patch/20200421002333.111461-6-heiko at sntech.de/ and other patches in that series