All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2] <pkg>-rsync: support user custom cmds
Date: Wed, 21 Aug 2013 18:41:06 +0200	[thread overview]
Message-ID: <5214EDA2.5050904@mind.be> (raw)
In-Reply-To: <CAEvN+1hRHX-RmBU67sRM7PS43N+XfoUQZOOQ1JYJsVp=DAe2rQ@mail.gmail.com>

On 08/21/13 09:20, Tzu-Jung Lee wrote:
> On Wed, Aug 21, 2013 at 2:09 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>> On 08/20/13 20:14, Tzu-Jung Lee wrote:
>>>
[snip]
>>> If we're considering efficiency for some cases, especially those have
>>> giant VCS
>>> database such as linux kernel, I think the combination of the two
>>> patches proposed
>>> already simple enough. They don't really add that much of complexity, I
>>> think.
>>>
>>>    1. Support customized RSYNC (this patch)
>>
>>
>>   Like Thomas, I really don't see the point of being able to choose cp
>> instead of rsync.
>>
>>>    2. Allow each package add their post-rsync hook if they need.
>>
>>   Adding the VCS stuff in a post-rsync-hook is really hackish.
>>
>>   Instead, I think the rsync command should use $($(PKG)_RSYNC_OPTS), which
>> allows the user to specify additional --include options in the override.mk
>> file. The documentation of the override.mk file should also be updated to
>> explain this possibility.
>
> $($(PKG)_RSYNC_OPTS) alone only gives the choice to sync / cp them or not.
>
> In some cases we actually prefer to simply link the VCS stuff instead
> of copying it
> to the build directory, especially if the VCS of the package is very huge.
>
> Not only the time taken by rsyncing them from a possibly networked mounted
> file system, but also the additional storage space taken by the build.
> If we are building multiple rootfs images that are built with Linux
> kernel from local
> source. It takes a few GB additional space in the build directories.
>
>
> So $($(PKG)_RSYNC_OPTS) can be replace the 1) custom RSYNC cmd patch.
> But we still need rsync-post-hook or other less hacky alternatives.

  Yes, that sounds reasonable.


  Regards,
  Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
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

      reply	other threads:[~2013-08-21 16:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-27 16:56 [Buildroot] [PATCH] <pkg>-rsync: support user custom cmds Tzu-Jung Lee
2013-07-28  8:22 ` Thomas De Schampheleire
2013-07-28 10:39   ` [Buildroot] [PATCH v2] " Tzu-Jung Lee
2013-07-28 13:03     ` Thomas Petazzoni
2013-07-28 13:15       ` Thomas De Schampheleire
2013-07-28 13:57         ` Thomas De Schampheleire
2013-07-28 14:17           ` Tzu-Jung Lee
2013-07-29  6:48             ` [Buildroot] [PATCH v3] " Tzu-Jung Lee
2013-08-07 19:59             ` [Buildroot] [PATCH v2] " Thomas De Schampheleire
2013-08-20 15:08               ` Thomas De Schampheleire
2013-08-20 18:14                 ` Tzu-Jung Lee
2013-08-21  6:09                   ` Arnout Vandecappelle
2013-08-21  7:20                     ` Tzu-Jung Lee
2013-08-21 16:41                       ` Arnout Vandecappelle [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=5214EDA2.5050904@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.