From: Richard Braun <rbraun@sceen.net>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] pkg-infra: limit -reconfigure and -rebuild actions
Date: Sat, 21 Jul 2012 01:31:36 +0200 [thread overview]
Message-ID: <20120720233136.GA25851@mail.sceen.net> (raw)
In-Reply-To: <20120720222722.5f89af04@skate>
On Fri, Jul 20, 2012 at 10:27:22PM +0200, Thomas Petazzoni wrote:
> Well, the use case for those targets was the following: I am making
> modifications to the source code of a package (especially using the
> OVERRIDE_SRCDIR mechanism) and I want to easily restart the build of
> that package and recreate the filesystem image so that I can test the
> new version of my package on the target. That's the reason why the
> target restarts the build *and* recreates the target filesystem.
To clarify my point of view: the intended behaviour is obvious, and
I assumed the original author knew what he wanted when these targets
were added. But my use cases are rather the following: I am making
modifications to the source code of a package, and I want to easily use
the environment provided by buildroot (the toolchain, the staging
directory and the target optimizations, maybe others). If it fails, it
will stop in either case. But if it succeeds, I want to easily check the
output and make sure the build process produced the expected results
(I mostly check compiler warnings, sometimes the generated code). If I
am confident in the results, I just add && make (which is short and
simple enough) to get the current behaviour.
I usually use buildroot with two flavors of configuration: a production
one, and a developer one (with debugging symbols, target debugging tools
such as valgrind, sometimes -O0 executables). This can result in huge
images, so getting to that step while the build of the package I'm
working on didn't reach a state I can confidently validate doesn't make
sense. And when it does (and even if it doesn't), simply adding
"&& make" does the job.
I'd also be glad to read from others, though, and hope you give much
attention to the code you're working on too :-).
--
Richard Braun
next prev parent reply other threads:[~2012-07-20 23:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-20 13:39 [Buildroot] [PATCH] pkg-infra: limit -reconfigure and -rebuild actions Richard Braun
2012-07-20 15:34 ` Émeric Vigier
2012-07-20 15:58 ` Richard Braun
2012-07-20 21:55 ` Émeric Vigier
2012-07-20 20:27 ` Thomas Petazzoni
2012-07-20 23:31 ` Richard Braun [this message]
2012-07-21 12:54 ` Thomas Petazzoni
2012-07-21 15:17 ` Richard Braun
2012-07-21 16:14 ` Samuel Martin
2012-07-22 18:27 ` Alex Bradbury
2012-12-14 13:49 ` Arnout Vandecappelle
2012-07-24 23:07 ` Arnout Vandecappelle
2012-08-02 13:28 ` Alex Bradbury
2012-08-02 13:36 ` Thomas Petazzoni
2012-09-21 16:57 ` Alex Bradbury
2012-07-22 19:20 ` Stephan Hoffmann
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=20120720233136.GA25851@mail.sceen.net \
--to=rbraun@sceen.net \
--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