Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC v3 00/30] Add per-package staging feature
Date: Thu, 18 Jun 2015 01:32:32 +0200	[thread overview]
Message-ID: <55820390.2070708@mind.be> (raw)
In-Reply-To: <CAHkwnC9wQZj6YxexYEt2fuZaeK_GD-S_BTg45wTcr9ZiLyKeKg@mail.gmail.com>

On 03/14/15 17:15, Fabio Porcedda wrote:
> On Thu, Mar 5, 2015 at 11:48 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
[snip]
>>  However, I don't like at all the approach of passing the custom -I and -L
>> flags. I think it's much better to start with something that was suggested
>> before in the BR developer meeting: use the toolchain wrapper also for the
>> internal toolchain. Then we can pass the per-package staging dir through the
>> environment, and use it in the --sysroot argument of the compiler.
>>
>>  We'll also have to do something about ccache then - that could be a problem.
>> Perhaps ccache should be called from within the wrapper as well, that may solve
>> a bunch of other ccache problems.
> 
> Using an internal wrapper we can also pass pass the -I and -L
> automatically like the --sysroot option?

 Yes we can. Of course, the path to the package sysroot has to be passed through
the environment.

> 
> If we use a per-package sysroot we need to copy the sysroot directory
> too, because the size of a uclibc sysroot is at least 11MB (if i
> remember correctly the size of a glibc sysroot is something like
> 40MB), so if we copy without using hard links, it will take at least
> 10MB up to 40MB for every package.
> 
> The size of the output directory of a defconfig + allyespackageconfig is 11GB.
> IMHO we have the following choices:
> a) common sysroot & per-package staging & without hard links
>   - the -I -L options are passed trough the toolchain wrapper
>   - output size is 16GB (11GB+5GB)

 Where does the 5GB come from? Experimental evidence from running this series?

>   - no side effects to fear, because hard links are not used
> b) per-package sysroot & without hard links
>   - sysroot are passed trough the toolchain wrapper
>   - output size will be 16GB plus 11MB * 694 = 16GB + 7GB = 23 GB
>   - no side effects to fear, because hard links are not used
> c) per-package sysroot & with hard links for toolchain
>  - sysroot are passed trough the toolchain wrapper
>   - output size will be 16GB
>   - side effects to fear for the toolchain files because hard links
> are used for them
> d) per-package sysroot & with hard links for all files
>  - sysroot are passed trough the toolchain wrapper
>   - output size will be 11GB, so no increased size
>   - side effects to fear because hard links are used

 Actually I'm not really concerned about the size, even if it's more than
doubled by this feature. We use factors less space than yocto so we can afford
to double it :-)

 I'm more concerned about the time penalty of copying things around all the
time. So in that respect, option a) or d) are more attractive. But even creating
all the hardlinks takes a lot of time (probably not that much faster than copying).

 A completely wild alternative is to build and use unionfs-fuse, but that
requires fusermount to be properly installed on the host. Can we assume that?

> 
> The cheaper one with almost no size and speed penalization is d) but
> if some file is overwritten other package sysroot could be affected.
> Maybe we can prevent the overwriting by removing the write permission
> on staging files?

 Yep, that's an option. It can actually be done while rsyncing.


 Regards,
 Arnout

> 
> Which solution is most suited for  buildroot?
> 
> Thanks and my BR
> 


-- 
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:[~2015-06-17 23:32 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-03  9:17 [Buildroot] [RFC v3 00/30] Add per-package staging feature Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 01/30] rtmpdump: use TARGET_LDFLAGS instead of TARGET_CFLAGS for XLDFLAGS Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 02/30] xinetd: use TARGET_LDFLAGS in order to support per-package staging Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 03/30] iproute2: use the TARGET_LDFLAGS variable Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 04/30] opentyrian: use TARGET_LDFLAGS Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 05/30] pppd: " Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 06/30] openswan: set LDFLAGS Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 07/30] exim: use TARGET_LDFLAGS Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 08/30] fbv: " Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 09/30] cups: " Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 10/30] faifa: " Fabio Porcedda
2015-03-03 16:57   ` Baruch Siach
2015-03-08 15:14     ` Fabio Porcedda
2015-03-08 15:18       ` Baruch Siach
2015-03-08 15:30         ` Fabio Porcedda
2015-03-08 16:28           ` Baruch Siach
2015-03-03  9:17 ` [Buildroot] [RFC v3 11/30] iw: use TARGET_CONFIGURE_OPTS Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 12/30] dhcpdump: use TARGET_CONFIGURE_OPTS in order to support PPS Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 13/30] dtc: add add support for per-package staging directory Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 14/30] openssh: add support to the " Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 15/30] mjpg-streamer: add support for " Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 16/30] tcpreplay: delay the execution of pcap-config Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 17/30] erlang: add support for the per-package staging directory Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 18/30] perl: don't loose the -shared flag when TARGET_LDFLAGS isn't empty Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 19/30] erlang-p1-iconv: bump to a version that use TARGET_CFLAGS Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 20/30] erlang-p1-zlib: " Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 21/30] lmbench: to be checked Fabio Porcedda
2015-03-03 16:56   ` Baruch Siach
2015-03-08 14:53     ` Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 22/30] Makefile: add the STAGINGNOPKG_DIR variable Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 23/30] gpsd: add support for per-package staging directory Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 24/30] triggerhappy: " Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 25/30] ipsec-tools: " Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 26/30] pkg-cmake: " Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 27/30] pkg-luarocks: " Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 28/30] pkgconf: Move PKG_CONFIG_HOST_BINARY to Makefile.in Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 29/30] pkg-generic: ADD_TOOLCHAIN_DEPENDENCY is true only for target packages Fabio Porcedda
2015-03-03  9:17 ` [Buildroot] [RFC v3 30/30] pkg-generic: add support for per-package staging directory Fabio Porcedda
2015-03-06  0:28   ` Arnout Vandecappelle
2015-05-13  6:22     ` Fabio Porcedda
2015-03-03 13:29 ` [Buildroot] [RFC v3 00/30] Add per-package staging feature Thomas Petazzoni
2015-03-03 14:03   ` Fabio Porcedda
2015-03-03 14:21     ` Thomas Petazzoni
2015-03-11 17:29       ` Fabio Porcedda
2015-03-05  3:54   ` Jérôme Oufella
2015-03-05  8:14     ` Fabio Porcedda
2015-03-05 22:48   ` Arnout Vandecappelle
2015-03-14 16:15     ` Fabio Porcedda
2015-06-17 23:32       ` Arnout Vandecappelle [this message]
2015-06-28 15:51         ` Fabio Porcedda
2015-06-12 20:14 ` Thomas Petazzoni
2015-06-15  9:06   ` Fabio Porcedda
2015-06-15  9:17     ` Thomas Petazzoni
2015-06-17 23:09       ` Arnout Vandecappelle
2015-06-28 15:36         ` Fabio Porcedda
2015-06-28 18:13           ` Thomas Petazzoni
2015-06-28 15:33       ` Fabio Porcedda
2015-06-28 18:12         ` Thomas Petazzoni
2015-06-28 19:34           ` Fabio Porcedda

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=55820390.2070708@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