Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC v1] Prototype implementation of per-package out of tree build
Date: Thu, 24 Jan 2013 21:12:53 +0100	[thread overview]
Message-ID: <510195C5.1050403@mind.be> (raw)
In-Reply-To: <1358725943-31485-1-git-send-email-thomas.petazzoni@free-electrons.com>

On 01/21/13 00:52, Thomas Petazzoni wrote:
[snip]
>   * The semantic of the 'make <pkg>-dirclean' command. Should it remove
>     the build directory and the source directory? Only the build
>     directory? If it removes both (which the proposed prototype
>     currently does), it is strange because you remove one build variant
>     (host or target) and the source directory, but the other build
>     variant (target or host) remains.

  I think the typical usecase for <pkg>-dirclean is when the patches have 
changed. So clearly the source should be removed as well. As mentioned by 
Stephan, Ideally the host-<pkg> build dir should be removed as well, but 
I think this is not that important because the newly patched files will 
have a more recent timestamp so the corresponding host-binaries should be 
rebuilt automatically.


>   * I am not sure on how we want to handle <pkg>-reconfigure and
>     <pkg>-rebuild. I guess we want to tell the user to do his changes
>     in the package source directory, output/src/<pkg>-<version>. But
>     all files in this source directory are marked read-only, so it's
>     not very practical.

  First of all, <pkg>-re{configure,build} is often used with 
OVERRIDE_SRCDIR so there you don't have a problem.

  If people do edit directly in the output/src directory, I think it is 
_very_ good that they have to 'chmod +w' first, as a reminder that 
editing in output/src is a bit risky. And once you've chmod'ed it, it 
stays writable because the chmod a-w is done at the end of the patch step.

  So I don't think there's an issue for <pkg>-re{configure,build}.


>     In addition to this, for packages that don't support out of tree
>     build, we do a rsync at the beginning of the configure step. So if
>     the user does "make <pkg>-reconfigure", then the source code gets
>     rsynced again from the source directory to the build directory, but
>     not if the user does "make <pkg>-rebuild".

  That's not so good. It could be solved by using the same mechanism that 
is currently used by OVERRIDE_SRCDIR: add an intermediate <pkg>-rsync 
target and stamp file, and remove the stamp file in 
<pkg>-clean-for-re{configure,build}.


  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

  parent reply	other threads:[~2013-01-24 20:12 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-20 23:52 [Buildroot] [RFC v1] Prototype implementation of per-package out of tree build Thomas Petazzoni
2013-01-20 23:52 ` [Buildroot] [RFC v1 01/14] Add a new "src" directory in the output directory Thomas Petazzoni
2013-01-21 13:47   ` Jérôme Pouiller
2013-01-21 17:16     ` Thomas Petazzoni
2013-01-22 10:15       ` Jérôme Pouiller
2013-01-22 16:49         ` Thomas Petazzoni
2013-01-22 17:12           ` Jérôme Pouiller
2013-01-23 15:45             ` Thomas Petazzoni
2013-01-24 10:34               ` Jérôme Pouiller
2013-01-20 23:52 ` [Buildroot] [RFC v1 02/14] package infrastructure: move subdir support to autotools Thomas Petazzoni
2013-01-20 23:52 ` [Buildroot] [RFC v1 03/14] generic infrastructure: out of tree build support Thomas Petazzoni
2013-01-24 21:41   ` Arnout Vandecappelle
2013-01-20 23:52 ` [Buildroot] [RFC v1 04/14] autotools infrastructure: support out of tree build Thomas Petazzoni
2013-01-24 21:57   ` Arnout Vandecappelle
2013-01-20 23:52 ` [Buildroot] [RFC v1 05/14] autotools infrastructure: do the autoreconf as a post patch step Thomas Petazzoni
2013-01-26 22:03   ` Arnout Vandecappelle
2013-01-27 16:27     ` Thomas Petazzoni
2013-01-27 22:18       ` Arnout Vandecappelle
2013-01-28  8:13         ` Thomas Petazzoni
2013-01-20 23:52 ` [Buildroot] [RFC v1 06/14] cmake infrastructure: support out of tree build Thomas Petazzoni
2013-01-20 23:52 ` [Buildroot] [RFC v1 07/14] busybox: " Thomas Petazzoni
2013-01-20 23:52 ` [Buildroot] [RFC v1 08/14] mtd: " Thomas Petazzoni
2013-01-20 23:52 ` [Buildroot] [RFC v1 09/14] barebox: " Thomas Petazzoni
2013-01-20 23:52 ` [Buildroot] [RFC v1 10/14] uboot: " Thomas Petazzoni
2013-01-20 23:52 ` [Buildroot] [RFC v1 11/14] linux: " Thomas Petazzoni
2013-01-20 23:52 ` [Buildroot] [RFC v1 12/14] autoconf: fix out-of-tree build Thomas Petazzoni
2013-01-20 23:52 ` [Buildroot] [RFC v1 13/14] cmake: support out of tree build Thomas Petazzoni
2013-01-20 23:52 ` [Buildroot] [RFC v1 14/14] makedevs: " Thomas Petazzoni
2013-01-21  4:24 ` [Buildroot] [RFC v1] Prototype implementation of per-package out oftree build Przemyslaw Wrzos
2013-01-21 17:26   ` Thomas Petazzoni
2013-01-21 18:51     ` Stephan Hoffmann
2013-01-24 20:12 ` Arnout Vandecappelle [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-01-20 20:25 [Buildroot] [RFC v1] Prototype implementation of per-package out of tree build Thomas Petazzoni
2013-01-22 21:11 ` Avery Pennarun

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=510195C5.1050403@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