[1/2] mxs-bootlets: add support for custom patches

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 boot/mxs-bootlets/Config.in       | 9 +++++++++
 boot/mxs-bootlets/mxs-bootlets.mk | 8 ++++++++
 2 files changed, 17 insertions(+)

On 18/05/13 21:25, Gustavo Zacarias wrote:
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> ---
>   boot/mxs-bootlets/Config.in       | 9 +++++++++
>   boot/mxs-bootlets/mxs-bootlets.mk | 8 ++++++++
>   2 files changed, 17 insertions(+)
>
> diff --git a/boot/mxs-bootlets/Config.in b/boot/mxs-bootlets/Config.in
> index 2222ff6..9dc2d37 100644
> --- a/boot/mxs-bootlets/Config.in
> +++ b/boot/mxs-bootlets/Config.in
> @@ -37,6 +37,15 @@ config BR2_TARGET_MXS_BOOTLETS_CUSTOM_GIT_VERSION
>
>   endif
>
> +config BR2_TARGET_MXS_BOOTLETS_CUSTOM_PATCH_DIR
> +	string "custom patch dir"
> +	help
> +	  If your board requires custom patches, add the path to the
> +	  directory containing the patches here. The patches must be
> +	  named mxs-bootlets-<something>.patch.
> +
> +	  Most users may leave this empty
> +

  Now that we have BR2_GLOBAL_PATCH_DIR, I would prefer to avoid adding 
config options like this... Admittedly, for bootloaders it is more likely 
that custom patches are needed than for any other package. But even so, 
the global patch dir is sufficient, it is quite useable, and it reduces 
complexity in the buildroot core.

  Regards,
  Arnout

>   choice
>   	prompt "Bootstream"
>   	help
> diff --git a/boot/mxs-bootlets/mxs-bootlets.mk b/boot/mxs-bootlets/mxs-bootlets.mk
> index f93ff81..6b18fcc 100644
> --- a/boot/mxs-bootlets/mxs-bootlets.mk
> +++ b/boot/mxs-bootlets/mxs-bootlets.mk
> @@ -4,6 +4,14 @@
>   #
>   #############################################################
>
> +ifneq ($(call qstrip,$(BR2_TARGET_MXS_BOOTLETS_CUSTOM_PATCH_DIR)),)
> +define MXS_BOOTLETS_APPLY_CUSTOM_PATCHES
> +	support/scripts/apply-patches.sh $(@D) $(BR2_TARGET_MXS_BOOTLETS_CUSTOM_PATCH_DIR) \
> +		mxs-bootlets-\*.patch
> +endef
> +MXS_BOOTLETS_POST_PATCH_HOOKS += MXS_BOOTLETS_APPLY_CUSTOM_PATCHES
> +endif
> +
>   ifeq ($(BR2_TARGET_MXS_BOOTLETS_CUSTOM_TARBALL),y)
>   	MXS_BOOTLETS_TARBALL = $(call qstrip,$(BR2_TARGET_MXS_BOOTLETS_CUSTOM_TARBALL_URL))
>   	MXS_BOOTLETS_SITE = $(patsubst %/,%,$(dir $(MXS_BOOTLETS_TARBALL)))
>

Dear Arnout Vandecappelle,

On Wed, 22 May 2013 08:08:22 +0200, Arnout Vandecappelle wrote:

> > +config BR2_TARGET_MXS_BOOTLETS_CUSTOM_PATCH_DIR
> > +	string "custom patch dir"
> > +	help
> > +	  If your board requires custom patches, add the path to the
> > +	  directory containing the patches here. The patches must be
> > +	  named mxs-bootlets-<something>.patch.
> > +
> > +	  Most users may leave this empty
> > +
> 
>   Now that we have BR2_GLOBAL_PATCH_DIR, I would prefer to avoid adding 
> config options like this... Admittedly, for bootloaders it is more likely 
> that custom patches are needed than for any other package. But even so, 
> the global patch dir is sufficient, it is quite useable, and it reduces 
> complexity in the buildroot core.

This means that a defconfig would have to define a value for
BR2_GLOBAL_PATCH_DIR, in this particular case. Is this something we
really want?

Also, what about the existing *_CUSTOM_PATCH_DIR config options we have
for Linux, U-Boot, Barebox and a bunch of other boot/kernel packages?

Thomas

On 22/05/13 08:58, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Wed, 22 May 2013 08:08:22 +0200, Arnout Vandecappelle wrote:
>
>>> +config BR2_TARGET_MXS_BOOTLETS_CUSTOM_PATCH_DIR
>>> +	string "custom patch dir"
>>> +	help
>>> +	  If your board requires custom patches, add the path to the
>>> +	  directory containing the patches here. The patches must be
>>> +	  named mxs-bootlets-<something>.patch.
>>> +
>>> +	  Most users may leave this empty
>>> +
>>
>>    Now that we have BR2_GLOBAL_PATCH_DIR, I would prefer to avoid adding
>> config options like this... Admittedly, for bootloaders it is more likely
>> that custom patches are needed than for any other package. But even so,
>> the global patch dir is sufficient, it is quite useable, and it reduces
>> complexity in the buildroot core.
>
> This means that a defconfig would have to define a value for
> BR2_GLOBAL_PATCH_DIR, in this particular case. Is this something we
> really want?

  I would say yes, I'd prefer that defconfigs define BR2_GLOBAL_PATCH_DIR 
to point to board/xxx/yyy/patches. Then they come much closer to how you 
would use buildroot in practice.


> Also, what about the existing *_CUSTOM_PATCH_DIR config options we have
> for Linux, U-Boot, Barebox and a bunch of other boot/kernel packages?

  Here also I'm in favour of deprecating them.

  But probably it's better to start using the global patch dir now, and 
only start deprecating the old ways next year.


  Regards,
  Arnout


>
> Thomas
>

On 05/22/2013 04:01 AM, Arnout Vandecappelle wrote:

>> Also, what about the existing *_CUSTOM_PATCH_DIR config options we have
>> for Linux, U-Boot, Barebox and a bunch of other boot/kernel packages?
> 
>  Here also I'm in favour of deprecating them.
> 
>  But probably it's better to start using the global patch dir now, and
> only start deprecating the old ways next year.
> 
> 
>  Regards,
>  Arnout

Ok, let's go for BR2_GLOBAL_PATCH_DIR, sent a V2 respinned.
Regards.