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