From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/2] x-loader: add custom git and tarball support
Date: Sat, 11 Feb 2012 15:55:12 +0100 [thread overview]
Message-ID: <201202111555.13197.arnout@mind.be> (raw)
In-Reply-To: <1328799108-19521-2-git-send-email-yegorslists@googlemail.com>
On Thursday 09 February 2012 15:51:48 yegorslists at googlemail.com wrote:
> From: Yegor Yefremov <yegorslists@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
next prev parent reply other threads:[~2012-02-11 14:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-09 14:51 [Buildroot] [PATCH 1/2] u-boot: begin custom patch dir with a capital yegorslists at googlemail.com
2012-02-09 14:51 ` [Buildroot] [PATCH 2/2] x-loader: add custom git and tarball support yegorslists at googlemail.com
2012-02-11 14:55 ` Arnout Vandecappelle [this message]
2012-02-13 8:13 ` Yegor Yefremov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201202111555.13197.arnout@mind.be \
--to=arnout@mind.be \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox