Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] force rsync of local package and try to rebuild it with its dependencies
Date: Thu, 2 Jul 2015 23:22:30 +0200	[thread overview]
Message-ID: <5595AB96.7020401@mind.be> (raw)
In-Reply-To: <20150702123528.1d32089a@free-electrons.com>

On 07/02/15 12:35, Thomas Petazzoni wrote:
> Dear Anthony Viallard,
> 
> On Thu,  2 Jul 2015 11:15:15 +0200, Anthony Viallard wrote:
>> The purpose of this patch is to force rsync of local site packages and
>> rebuild them if their source code has changed. Therefore, if the source
>> of a package has changed, it will be rebuild if you type make or
>> make <pkg>. Likewise, if a package has a library dependency which is
>> local site package too and you type make <pkg>, the library will be
>> rebuild if the source has been modified.
>>
>> This behavior is pretty useful if you use buildroot with many of your
>> own packages. Especially if you share these packages with a developer
>> team through a version control system like git.
> 
> Again, I don't think we want this change in Buildroot. I don't think we
> want *all* local packages to systematically be rsync'ed and rebuilt, at
> every "make" invocation.

 Actually, why not? Ideally, we would like to rebuild everything every time -
but that just takes too long. However, we can assume that there aren't so many
local packages, so their rebuild does not necessarily take too long.

 So I went and did an experiment on my laptop (HDD, 8GB RAM, so relatively
slow): when nothing actually has to be rebuilt, 'make linux-rebuild' takes 40s
longer than 'make linux'. (I'm taking linux because that's the one where we can
expect the most overhead from rebuilding.)  That is the same amount of time as
building a small package like xz.

 Conclusion: indeed, we shouldn't do rebuilding of local packages by default.

> 
> Maybe we want a separate "make rebuild-local" target (not sure of the
> name), which would trigger this special action. Local packages could be
> all registered in a global LOCAL_PACKAGES variable, and make
> rebuild-local would rebuild them all.
> 
> Note that you could also solve this problem by adding something like
> that in your external.mk (provided you're using BR2_EXTERNAL):

 Or in your local.mk (BR2_PACKAGE_OVERRIDE_FILE), where you put these overrides.

> 
> # Needs to be filled in with your complete list of packages
> CUSTOM_PACKAGES = foo1 foo2 foo3
> 
> rebuild-custom: $(foreach p,$(CUSTOM_PACKAGES),$(p))

 Or if you don't want to call a specific target:

world: $(foreach p,$(CUSTOM_PACKAGES),$(p))

That way, you can just type 'make' and it will rebuild your custom packages.


> 
>> -	rsync -au $(RSYNC_VCS_EXCLUSIONS) $(SRCDIR)/ $(@D)
>> +	rsync -au $(RSYNC_VCS_EXCLUSIONS) --include core $(SRCDIR)/ $(@D)
> 
> This change is unrelated to the patch I believe.

 And it should be added to RSYNC_VCS_EXCLUSIONS instead.

 However, why is this even needed? RSYNC_VCS_EXCLUSIONS doesn't exclude any
pattern that matches 'core'.


 Regards,
 Arnout


> 
> Best regards,
> 
> Thomas
> 


-- 
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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

      reply	other threads:[~2015-07-02 21:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-02  9:15 [Buildroot] [PATCH 1/1] force rsync of local package and try to rebuild it with its dependencies Anthony Viallard
2015-07-02 10:35 ` Thomas Petazzoni
2015-07-02 21:22   ` 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=5595AB96.7020401@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