From: "Jérôme Pouiller" <jezz@sysmic.org>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] pkg-infra: log current message
Date: Mon, 07 Oct 2013 21:46:28 +0200 [thread overview]
Message-ID: <3623578.UApTusJAiV@sagittae> (raw)
In-Reply-To: <20131007164829.GB9561@free.fr>
On Monday 07 October 2013 18:48:29 Yann E. MORIN wrote:
> Thomas, J?r?me, All,
>
> On 2013-10-07 14:07 +0200, Thomas Petazzoni spake thusly:
> > Dear J?r?me Pouiller,
> >
> > On Mon, 07 Oct 2013 12:09:50 +0200, J?r?me Pouiller wrote:
> > > I have also in my local git some branches modified in a similar
> > > fashion. Some weeks ago, Francois Perrad also suggested a patch
> > > with a similar modification
> > > (http://patchwork.ozlabs.org/patch/265214). Thomas also wrote a
> > > patch to get build time statistics
> > > (http://lists.busybox.net/pipermail/buildroot/2011-October/046513.
> > > html).
> > >
> > > IMHO, these patchs are too much specific and should not be
> > > mainlined.
> >
> > I am not sure I agree here. The fact that several of us have such
> > patches, and that they would indeed be useful to produce build time
> > statistics, or help the autobuilders provide better diagnostics
> > could
> > be useful. I believe that it's the real strength of the common
> > package infrastructure: we can add such additional features on all
> > packages at once, very easily. Of course, it should be implemented
> > in a nice and clean way that doesn't complexity too much the core
> > package
> > infrastructure, but it's very likely easy to achieve with some
> > hooks.
>
> What about adding a new Kconfig option like:
>
> config BR2_BUILD_INFRA_STEP_SCRIPT
> bool "script to run before and after each step"
> help
> Buildroot will call this script before executing any single
> step in the build process. The arguments to this script are:
> $1: either "pre" or "post", resp. meaning "before" or "after" the
> step
> $2: name of the package
> $3: version of the package
Let's try to find a way to pass all VARIABLE relative to the package
(version, dependencies, url, buildir, etc...). We may also want to pass
TARGETDIR, HOSTDIR, etc... I thought to pass them using environment.
Else, it's good for me.
> $4: action to be done
>
> Leave empty (the default) to not run any script.
>
> It would then be the responsibility of the user to provide such a
> script. We could provide a simple script that just do this logging as
> an example.
--
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr
next prev parent reply other threads:[~2013-10-07 19:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-06 11:19 [Buildroot] [PATCH] pkg-infra: log current message Yann E. MORIN
2013-10-06 14:31 ` Thomas Petazzoni
2013-10-07 10:09 ` Jérôme Pouiller
2013-10-07 12:07 ` Thomas Petazzoni
2013-10-07 16:48 ` Yann E. MORIN
2013-10-07 16:59 ` Yann E. MORIN
2013-10-07 17:19 ` Thomas Petazzoni
2013-10-08 16:47 ` Arnout Vandecappelle
2013-10-07 20:53 ` Jérôme Pouiller
2013-10-07 19:46 ` Jérôme Pouiller [this message]
2013-10-08 16:53 ` Arnout Vandecappelle
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=3623578.UApTusJAiV@sagittae \
--to=jezz@sysmic.org \
--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