[Buildroot] [PATCH 2/2] x-loader: add custom git and tarball support

Arnout Vandecappelle arnout at mind.be
Sat Feb 11 14:55:12 UTC 2012


On Thursday 09 February 2012 15:51:48 yegorslists at googlemail.com wrote:
> From: Yegor Yefremov <yegorslists at googlemail.com>

 First some general remarks:

- Make sure that existing (def)configs keep working as expected.  So
setting BR2_TARGET_XLOADER and BR2_TARGET_XLOADER_BOARDNAME should be
enough to get a working xloader.

- Are there actual public xloader tarballs that you would use?  If the
purpose is to avoid git clones from gitorious, it's better to use the 
PRIMARY_SITE feature.  If the purpose is to use a locally modified
version, it's better to use the _OVERRIDE_SRCDIR feature.  And if the
purpose is to avoid requiring git access, it's better to change the
XLOADER_SITE to http://gitorious.org/x-loader/x-loader/archive-tarball
and XLOADER_SOURCE to v1.5.1 (this is a version bump as well, obviously).


> +choice
> +	prompt "X-loader Version"
> +	default BR2_TARGET_XLOADER_CUSTOM_GIT
> +	help
> +	  Select the specific X-loader version you want to use
> +
> +config BR2_TARGET_XLOADER_CUSTOM_TARBALL
> +	bool "Custom tarball"
> +
> +config BR2_TARGET_XLOADER_CUSTOM_GIT
> +	bool "Custom Git repository"

 Since you have to choose one of the two, it's strange to call them
"custom".  Also, git comes before tarball in the alphabet.

 Perhaps the best option is to add 'v1.5.1' as one of the options,
that also solves my issue with existing defconfigs no longer working.

[snip]
> +config BR2_TARGET_XLOADER_VERSION
> +	string
> +	default "custom"	if BR2_TARGET_XLOADER_CUSTOM_TARBALL
> +	default $BR2_TARGET_XLOADER_CUSTOM_GIT_VERSION if BR2_TARGET_XLOADER_CUSTOM_GIT

 I didn't know that it worked with the $.  Is there a difference between
with and without?  If not, Peter, do we have a preference?

> +
> +config BR2_TARGET_XLOADER_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 xloader-<version>-<something>.patch.

 Leave the version out of the name.  Especially if <version> is a git
sha, this becomes annoyingly long.

 At the developer day, we decided that internal patches normally have no
version number, and that if one is required (because multiple versions of
the package exist), each version will have a separate directory.  For 
external patches, the same pattern should be allowed.

 The linux patches require linux-*.patch, u-boot currently requires the
version number to be there (but that will change I guess).


> +ifeq ($(XLOADER_VERSION),custom)
 A git branch may be called 'custom', so this is no reliable way to detect
git vs. tarball.  But you can simply put
ifeq ($(BR2_TARGET_XLOADER_CUSTOM_TARBALL),y)

> +# Handle custom X-loader tarballs as specified by the configuration
 This remark is redundant.

> +XLOADER_TARBALL = $(call qstrip,$(BR2_TARGET_XLOADER_CUSTOM_TARBALL_LOCATION))
> +XLOADER_SITE    = $(dir $(XLOADER_TARBALL))
> +XLOADER_SOURCE  = $(notdir $(XLOADER_TARBALL))
> +else
> +XLOADER_SITE        = $(call qstrip,$(BR2_TARGET_XLOADER_CUSTOM_GIT_REPO_URL))
> +XLOADER_SITE_METHOD = git
> +endif
> +
> +ifneq ($(call qstrip,$(BR2_TARGET_XLOADER_CUSTOM_PATCH_DIR)),)
> +define XLOADER_APPLY_CUSTOM_PATCHES
> +	support/scripts/apply-patches.sh $(@D) $(BR2_TARGET_XLOADER_CUSTOM_PATCH_DIR) \
> +		xloader-$(XLOADER_VERSION)-\*.patch
> +endef
> +
> +XLOADER_POST_PATCH_HOOKS += XLOADER_APPLY_CUSTOM_PATCHES
> +endif
> +
>  XLOADER_INSTALL_IMAGES = YES
>  
>  define XLOADER_BUILD_CMDS


 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F


More information about the buildroot mailing list