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
next prev 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