Patchwork pkg-infra: log current message

login
register
mail settings
Submitter Arnout Vandecappelle
Date Oct. 8, 2013, 4:53 p.m.
Message ID <5254389E.4090007@mind.be>
Download mbox | patch
Permalink /patch/281540/
State Not Applicable
Headers show

Comments

Arnout Vandecappelle - Oct. 8, 2013, 4:53 p.m.
On 10/07/13 18:48, 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
>                $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.

 I think that this kind of stuff is really orthogonal to the configuration. 
It is rather something local to the developer's environment. Therefore, I 
think it should be something that is defined in the local.mk.

 For instance:



 This also makes all make variables accessible in the hook, avoiding the 
problem that Jérôme pointed out.


 Regards,
 Arnout

Patch

diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index bfc4dc1..ac44565 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -108,10 +108,12 @@  $(BUILD_DIR)/%/.stamp_patched:
 
 # Configure
 $(BUILD_DIR)/%/.stamp_configured:
+       $(foreach hook,$(GENERIC_HOOKS),$(call $(hook),pre,configure)$(sep))
        $(foreach hook,$($(PKG)_PRE_CONFIGURE_HOOKS),$(call $(hook))$(sep))
        @$(call MESSAGE,"Configuring")
        $($(PKG)_CONFIGURE_CMDS)
        $(foreach hook,$($(PKG)_POST_CONFIGURE_HOOKS),$(call $(hook))$(sep))
+       $(foreach hook,$(GENERIC_HOOKS),$(call $(hook),post,configure)$(sep))
        $(Q)touch $@
 
 # Build