Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yegor Yefremov <yegor_sub1@visionsystems.de>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/2] x-loader: add custom git and tarball support
Date: Mon, 13 Feb 2012 09:13:24 +0100	[thread overview]
Message-ID: <4F38C624.7020505@visionsystems.de> (raw)
In-Reply-To: <201202111555.13197.arnout@mind.be>

Am 11.02.2012 15:55, schrieb Arnout Vandecappelle:
> 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).

I think we don't really need support for tarballs. I've just taken the u-boot approach.
 
>> +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.

ACK
 
>  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.

ACK
 
> [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.

Oh yes, it is annoying.
 
>  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.

I support this decision.

>  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.

ACK

>> +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

I'm using am3517 based board and it's x-loader is still in arago repo. That's why I wanted to introduce alternative x-loader repo. But after getting feedback from Arago, I would postpone reworking this patch and trying to get x-loader upstream. With arago repo I still have a problem, that signPG is missing. Had made a patch to solve this, but getting am3517 upstream were the best solution.

Yegor

      reply	other threads:[~2012-02-13  8:13 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
2012-02-13  8:13     ` Yegor Yefremov [this message]

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=4F38C624.7020505@visionsystems.de \
    --to=yegor_sub1@visionsystems.de \
    --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