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