| Message ID | 1482203412-5361-1-git-send-email-danomimanchego123@gmail.com |
|---|---|
| State | Accepted |
| Commit | f61583fc2eb0ebf1d712581c2dae60e8fb692973 |
| Headers | show |
>>>>> "Danomi" == Danomi Manchego <danomimanchego123@gmail.com> writes: > Commit 3e3fef39e71ed0426130b36aa00e4630ebb537ae added new and improved > patch handling, with BR2_TARGET_UBOOT_PATCH. This was in addition to > the existing BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR option, that only > handled directories. > Later, commit 21b25d28fc7af3bb1b2c55e4a46e0d067ebc0081 moved the old > BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR to legacy options. But on the way, > bad things happened: > * The original option was a string, while the one added to Config.in.legacy > is a bool. This results in a warning from defconfigs that actually define > the old BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR (because a string is not a valid > value for a bool), but it does not result in the legacy option being > selected. Consequently, BR2_LEGACY is not selected either. > * The advice at the top of Config.in.legacy to add a hidden WRAP option > to select BR2_LEGACY was not heeded. > * The advice at the top of Config.in.legacy to use the old string > option as the default for the new string option was not heeded. In > this case, the variable was not just renamed, as the old option > supported directories only, while the new one supports files too. > But since the old option is a subset of the new option, it can still > be used to set a useful default. > So, this mod turns the legacy option back to a string, adds a hidden > bool WRAP option to set BR2_LEGACY when the string is non emoty, and > uses the legacy option to set the default for the new option. > Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com> Nice detailed description! Committed, thanks.
On 20-12-16 10:06, Peter Korsgaard wrote: >>>>>> "Danomi" == Danomi Manchego <danomimanchego123@gmail.com> writes: > > > Commit 3e3fef39e71ed0426130b36aa00e4630ebb537ae added new and improved > > patch handling, with BR2_TARGET_UBOOT_PATCH. This was in addition to > > the existing BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR option, that only > > handled directories. > > > Later, commit 21b25d28fc7af3bb1b2c55e4a46e0d067ebc0081 moved the old > > BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR to legacy options. But on the way, > > bad things happened: > > > * The original option was a string, while the one added to Config.in.legacy > > is a bool. This results in a warning from defconfigs that actually define > > the old BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR (because a string is not a valid > > value for a bool), but it does not result in the legacy option being > > selected. Consequently, BR2_LEGACY is not selected either. > > > * The advice at the top of Config.in.legacy to add a hidden WRAP option > > to select BR2_LEGACY was not heeded. > > > * The advice at the top of Config.in.legacy to use the old string > > option as the default for the new string option was not heeded. In > > this case, the variable was not just renamed, as the old option > > supported directories only, while the new one supports files too. > > But since the old option is a subset of the new option, it can still > > be used to set a useful default. > > > So, this mod turns the legacy option back to a string, adds a hidden > > bool WRAP option to set BR2_LEGACY when the string is non emoty, and > > uses the legacy option to set the default for the new option. > > > Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com> > > Nice detailed description! Committed, thanks. This is 2016.11.x material. Regards, Arnout
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: Hi, >> Nice detailed description! Committed, thanks. > This is 2016.11.x material. It has been broken since 2016.05-rc1, but OK - We can indeed add it for 2016.11.x
On Tue, Dec 20, 2016 at 4:04 PM, Peter Korsgaard <peter@korsgaard.com> wrote: >>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: > > Hi, > > >> Nice detailed description! Committed, thanks. > > > This is 2016.11.x material. > > It has been broken since 2016.05-rc1, but OK - We can indeed add it for > 2016.11.x I noticed it now because we are upgrading from 2014.05 to 2016.11. We use both the uboot custom patch dir feature (replaced) and the linux custom path feature (dropped, frowny face), so I'm hitting those right now. Danomi -
>>>>> "Danomi" == Danomi Manchego <danomimanchego123@gmail.com> writes: >> > This is 2016.11.x material. >> >> It has been broken since 2016.05-rc1, but OK - We can indeed add it for >> 2016.11.x > I noticed it now because we are upgrading from 2014.05 to 2016.11. We > use both the uboot custom patch dir feature (replaced) and the linux > custom path feature (dropped, frowny face), so I'm hitting those right > now. Ok. The replacement for both is simply BR2_GLOBAL_PATCH_DIR (with linux patches under linux/ and u-boot patches under uboot/). I've applied the fix to the the 2016.11.x branch and will include it in the upcoming 2016.11.1 release.
Hello, On Tue, 20 Dec 2016 22:45:49 +0100, Peter Korsgaard wrote: > > I noticed it now because we are upgrading from 2014.05 to 2016.11. We > > use both the uboot custom patch dir feature (replaced) and the linux > > custom path feature (dropped, frowny face), so I'm hitting those right > > now. > > Ok. The replacement for both is simply BR2_GLOBAL_PATCH_DIR (with linux > patches under linux/ and u-boot patches under uboot/). Not completely true: the "linux custom path" feature is not replaced by BR2_GLOBAL_PATCH_DIR. If one wants to get the same functionality, i.e telling Buildroot to use the Linux kernel source code from an available local directory, then the only solution is to use LINUX_OVERRIDE_SRCDIR. Best regards, Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > Hello, > On Tue, 20 Dec 2016 22:45:49 +0100, Peter Korsgaard wrote: >> > I noticed it now because we are upgrading from 2014.05 to 2016.11. We >> > use both the uboot custom patch dir feature (replaced) and the linux >> > custom path feature (dropped, frowny face), so I'm hitting those right >> > now. >> >> Ok. The replacement for both is simply BR2_GLOBAL_PATCH_DIR (with linux >> patches under linux/ and u-boot patches under uboot/). > Not completely true: the "linux custom path" feature is not replaced by > BR2_GLOBAL_PATCH_DIR. If one wants to get the same functionality, i.e > telling Buildroot to use the Linux kernel source code from an available > local directory, then the only solution is to use LINUX_OVERRIDE_SRCDIR. Sorry, I read it as 'custom patch' feature, not 'custom path'.
On Tue, Dec 20, 2016 at 5:00 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Hello, > > On Tue, 20 Dec 2016 22:45:49 +0100, Peter Korsgaard wrote: > >> > I noticed it now because we are upgrading from 2014.05 to 2016.11. We >> > use both the uboot custom patch dir feature (replaced) and the linux >> > custom path feature (dropped, frowny face), so I'm hitting those right >> > now. >> >> Ok. The replacement for both is simply BR2_GLOBAL_PATCH_DIR (with linux >> patches under linux/ and u-boot patches under uboot/). > > Not completely true: the "linux custom path" feature is not replaced by > BR2_GLOBAL_PATCH_DIR. If one wants to get the same functionality, i.e > telling Buildroot to use the Linux kernel source code from an available > local directory, then the only solution is to use LINUX_OVERRIDE_SRCDIR. Understood. It's just that using a custom path for boot loaders and the kernel is the norm for us, not an exception. In fact, I've never been on a project where we were able to use a main line kernel or uboot. Sometimes, we'll go through the exercise of making patches against an initial state of a vendor's git repo, but many of out project leaders prefer to just source control everything locally. Under those circumstances, it's nicer to have the local path in the defconfig than in a secondary local.mk or in the .mk file itself. Danomi -
Hello, On Tue, 20 Dec 2016 17:55:41 -0500, Danomi Manchego wrote: > Understood. It's just that using a custom path for boot loaders and > the kernel is the norm for us, not an exception. In fact, I've never > been on a project where we were able to use a main line kernel or > uboot. Sometimes, we'll go through the exercise of making patches > against an initial state of a vendor's git repo, but many of out > project leaders prefer to just source control everything locally. > Under those circumstances, it's nicer to have the local path in the > defconfig than in a secondary local.mk or in the .mk file itself. If your U-Boot / Linux kernel source code is under version control, why don't you ask Buildroot to pull it from your Git/SVN/Mercurial/whatever repository ? Thomas
On Tue, Dec 20, 2016 at 5:56 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Hello, > > On Tue, 20 Dec 2016 17:55:41 -0500, Danomi Manchego wrote: > >> Understood. It's just that using a custom path for boot loaders and >> the kernel is the norm for us, not an exception. In fact, I've never >> been on a project where we were able to use a main line kernel or >> uboot. Sometimes, we'll go through the exercise of making patches >> against an initial state of a vendor's git repo, but many of out >> project leaders prefer to just source control everything locally. >> Under those circumstances, it's nicer to have the local path in the >> defconfig than in a secondary local.mk or in the .mk file itself. > > If your U-Boot / Linux kernel source code is under version control, why > don't you ask Buildroot to pull it from your Git/SVN/Mercurial/whatever > repository ? Perforce integration with Makefiles can be - tricky. Our current setup is to use buildroot as the core for our build system, with all the proprietary apps and customized kernel and bootloader(s) at a level parallel to buildroot, but built using override source directories. So the whole thing (buildroot, proprietary apps, kernel, linux) are all checked at at once, not on a package by package basis. We keep a local cache of the package tarballs, so nothing is downloaded or pulled on-the-fly, buildroot-wise.
diff --git a/Config.in.legacy b/Config.in.legacy index b42eb41..b0ca2da 100644 --- a/Config.in.legacy +++ b/Config.in.legacy @@ -551,12 +551,19 @@ config BR2_PACKAGE_QT5QUICK1 from upstream starting from Qt 5.6. config BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR - bool "uboot custom patch dir removed" - select BR2_LEGACY + string "uboot custom patch dir has been removed" help The uboot custom patch directory option has been removed. Use the improved BR2_TARGET_UBOOT_PATCH option instead. +config BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR_WRAP + bool + default y if BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR != "" + select BR2_LEGACY + +# Note: BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR is still referenced from +# boot/uboot/Config.in + config BR2_PACKAGE_XDRIVER_XF86_INPUT_VOID bool "xf86-input-void removed" select BR2_LEGACY diff --git a/boot/uboot/Config.in b/boot/uboot/Config.in index 3b4bfac..2a9f14a 100644 --- a/boot/uboot/Config.in +++ b/boot/uboot/Config.in @@ -95,6 +95,7 @@ config BR2_TARGET_UBOOT_VERSION config BR2_TARGET_UBOOT_PATCH string "Custom U-Boot patches" + default BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR if BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR != "" # legacy help A space-separated list of patches to apply to U-Boot. Each patch can be described as an URL, a local file path,
Commit 3e3fef39e71ed0426130b36aa00e4630ebb537ae added new and improved patch handling, with BR2_TARGET_UBOOT_PATCH. This was in addition to the existing BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR option, that only handled directories. Later, commit 21b25d28fc7af3bb1b2c55e4a46e0d067ebc0081 moved the old BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR to legacy options. But on the way, bad things happened: * The original option was a string, while the one added to Config.in.legacy is a bool. This results in a warning from defconfigs that actually define the old BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR (because a string is not a valid value for a bool), but it does not result in the legacy option being selected. Consequently, BR2_LEGACY is not selected either. * The advice at the top of Config.in.legacy to add a hidden WRAP option to select BR2_LEGACY was not heeded. * The advice at the top of Config.in.legacy to use the old string option as the default for the new string option was not heeded. In this case, the variable was not just renamed, as the old option supported directories only, while the new one supports files too. But since the old option is a subset of the new option, it can still be used to set a useful default. So, this mod turns the legacy option back to a string, adds a hidden bool WRAP option to set BR2_LEGACY when the string is non emoty, and uses the legacy option to set the default for the new option. Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com> --- Config.in.legacy | 11 +++++++++-- boot/uboot/Config.in | 1 + 2 files changed, 10 insertions(+), 2 deletions(-)