From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/4] pkg-infra: introduce pre/post-step hooks
Date: Mon, 14 Oct 2013 18:50:14 +0200 [thread overview]
Message-ID: <20131014165014.GA3491@free.fr> (raw)
In-Reply-To: <20131014091609.06dcc63c@skate>
On 2013-10-14 09:16 +0200, Thomas Petazzoni spake thusly:
> Dear Yann E. MORIN,
>
> On Mon, 14 Oct 2013 01:11:25 +0200, Yann E. MORIN wrote:
> > From: "Yann E. MORIN" <yann.morin.1998@free.fr>
> >
> > This hooks will let us instrument the build process in many ways:
> > - log current step to see what broke
> > - time each step to see what is worth optimising
> > - sanity-check installed files (rpath, overwritten files...)
> > - call user-provided script
> > - ...
> >
> > The steps are fine-grain, and all have a 'start' and a 'end' hooks.
> > Here is the list of available steps (19 total):
> > - extract, post-extract
> > - pre-patch, patch, post-patch
> > - pre-configure, configure, post-configure
> > - build, post-build
> > - install-host, post-install-host
> > - install-staging, post-install-staging, pkg-config-staging
> > - install-image, post-install-image
> > - install-target, post-install-target
> >
> > The download, clean, uninstall steps are not instrumented on purpose.
> >
> > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
>
> I am not sure to follow why we're introducing additional hooks here.
> Why don't we generalize the existing pre/post hooks mechanism to *all*
> steps (by all I mean the steps you are interested in instrumenting),
> and use that to hook the different things you introduce in patch 2, 3,
> 4 ?
I'm not sure I understand what you suggest, so I'll try to explain what
I understood (in a series-like order):
- add missing pre/post hooks to all steps
- have the pkg-infra internally register pre/post hooks for each
package
- add and register the time/user hooks
Is that what you meant?
> Also, do we really need to have hook points for the pre-hooks and
> post-hooks each time?
Yes, I wan't to be able to instrument them. Especially, I want to be
able to check that pre/post hook are not messing with target/ in crazy
way. I also want to be able to time them (heck, I've seen a hook takes
orders of magnitude longer than the corresponding action).
With your suggestion, I don't know how we can instrument the pre/post
hooks.
Note: However, I agree that we could reduce the number of steps by
squashing, for example, end-pre-configure with start-configure, or
end-configure with start-post-configure (and so on). But having both
start/end be separate barriers is cleaner and more systematic; it helps
reviewing a log of the build without constantly wondering what frontier
a specific step is.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2013-10-14 16:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-13 23:11 [Buildroot] [pull request] [RFC] Pull request for branch yem/instrument-build Yann E. MORIN
2013-10-13 23:11 ` [Buildroot] [PATCH 1/4] pkg-infra: introduce pre/post-step hooks Yann E. MORIN
2013-10-14 7:16 ` Thomas Petazzoni
2013-10-14 16:50 ` Yann E. MORIN [this message]
2013-10-13 23:11 ` [Buildroot] [PATCH 2/4] pkg-infra: add hook to log timing of steps Yann E. MORIN
2013-10-13 23:11 ` [Buildroot] [PATCH 3/4] Makefile: export BUILD_DIR Yann E. MORIN
2013-10-14 10:54 ` Peter Korsgaard
2013-10-14 17:05 ` Yann E. MORIN
2013-10-13 23:11 ` [Buildroot] [PATCH 4/4] pkg-infra: add user-supplied step-hooks Yann E. MORIN
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=20131014165014.GA3491@free.fr \
--to=yann.morin.1998@free.fr \
--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.