From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] pkg-infra: limit -reconfigure and -rebuild actions
Date: Sat, 21 Jul 2012 14:54:11 +0200 [thread overview]
Message-ID: <20120721145411.6e291ad2@skate> (raw)
In-Reply-To: <20120720233136.GA25851@mail.sceen.net>
Le Sat, 21 Jul 2012 01:31:36 +0200,
Richard Braun <rbraun@sceen.net> a ?crit :
> 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.
Actually, the original author was me :-)
See 4ed4e5016b741341059ed826416dad3291df0b2c.
> 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.
It does make some sense, but I'd like to see the opinion of others.
However, I don't agree with the change you did on -reconfigure that
would only to the configure step. If -rebuild does build+install, then
-reconfigure should do configure+build+install.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2012-07-21 12:54 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
2012-07-21 12:54 ` Thomas Petazzoni [this message]
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=20120721145411.6e291ad2@skate \
--to=thomas.petazzoni@free-electrons.com \
--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.