ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] How to force a package build if its PRECONFIG changed?


From: Stuart Hughes
Subject: Re: [Ltib] How to force a package build if its PRECONFIG changed?
Date: Sat, 02 Apr 2011 11:55:55 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7

Okay, checked-in so I don't forget.  Let me know if anything is not as
expected.

On 27/03/11 21:23, Peter Barada wrote:
> Looks good at first blush, will give a whirl...
> 
> Splat-fingered from my iPhone
> 
> On Mar 27, 2011, at 3:34 PM, Stuart Hughes <address@hidden> wrote:
> 
>>
>>
>> On 22/03/11 21:10, Peter Barada wrote:
>>> On 03/22/2011 04:54 PM, Stuart Hughes wrote:
>>>> On 21/03/11 20:56, Peter Barada wrote:
>>>>> On 03/21/2011 03:56 PM, Peter Barada wrote:
>>>>>> Stuart,
>>>>>>
>>>>>> How can I have "./ltib" force a rebuild of a package (kernel, busybox, 
>>>>>> etc) if the content of its PRECONFIG file changed?  I.e. if I change the 
>>>>>> kernel or busybox .config file(i.e newer than the generated rpm file), 
>>>>>> how can i trigger a build of that package?
>>>>>>
>>>>>> I've gotten bitten by enabling CONFIG_FEATURE_IFCONFIG_HW in the 
>>>>>> busybox.config file I'm using and the automated build didn't detect that 
>>>>>> busybox needed to be rebuilt.
>>>>>>
>>>>>> I'll code it up and experimet, but I'm not sure how to get the dates for 
>>>>>> the preconfig and resultant rpm files(as my perl fu is weak).
>>>>>>
>>>>>> Any help is appreciated.
>>>>> I think I've figured it out.  Following in build_rpm looks to work (and 
>>>>> handles the case of a preconfig file being in either the platform or 
>>>>> defaults directory) after "my $dir_bld = ...":
>>>>>
>>>>>    my $preconfig_file = $pcf->{$key . "_PRECONFIG"};
>>>>>    my $preconfig_bld = 0;
>>>>>    if ( $preconfig_file ) {
>>>>>    my $dflts = "defaults";
>>>>>    if ( -f "$cf->{top}/$cf->{plat_dir}/$preconfig_file" ) {
>>>>>        $preconfig_file = "$cf->{top}/$cf->{plat_dir}/$preconfig_file";
>>>>>    } else {
>>>>>        if ( -f "${cf}->{config_dir}/$dflts/$preconfig_file" ) {
>>>>>        $preconfig_file = "${cf}->{config_dir}/$dflts/$preconfig_file";
>>>>>        }
>>>>>    }
>>>>>    if ( $rpms[0] && -f $rpms[0]) {
>>>>>        if ( -M $rpms[0] > -M $preconfig_file ) {
>>>>>        $preconfig_bld = 1;
>>>>>        }
>>>>>    }
>>>>>    }
>>>>>
>>>>> And then adding:
>>>>>    $r   .= "preconfig file changed, "   if $preconfig_bld;
>>>>>
>>>>> after "my $r = '';" in build_rpm()
>>>>>
>>>>> Of course there may be a much more efficient way to do this, any 
>>>>> suggestions appreciated!
>>>>>
>>>> Hi Peter,
>>>>
>>>> Our emails crossed in mid-foo. What you have above looks good.  If you
>>>> can integrate and test it, and send a patch, I'll get it merged.
>>> Stuart,  Attached.
>>>
>>> Note that my ltib script is different than what's in CVS as I have other 
>>> changes in place to support SVN builds.
>>>
>>> This patch is against the CVS version, using the bits I added into my ltib 
>>> script.  I've updated it to handle changes in kernel configuration files 
>>> (either the platform .config, or platform .config.dev), and have tested it 
>>> (in my LTIB script) with both the kernel and busybox in my buildbot 
>>> universe.  I haven't tested the CVS version of LTIB (as my project is a bit 
>>> behind that version), but feel it should work.
>>>
>>> On a separate note, how can I have ltib read in a file (that contains build 
>>> dependencies, list of variables to export into the shell environment, etc) 
>>> and incorporate it into ltib's perl environment such that my platform can 
>>> define extra package build dependencies, environment variables, etc w/o 
>>> having to hack up the ltib script itself?
>>>
>>>
>>>> Regards, Stuart
>>>
>>>
>>
>> Hi Peter,
>>
>> I've re-worked your patch a bit and I've attached it for you to look at
>> before I check it in.  The idea is that if any config is newer to mark a
>> rebuild as necessary and to action it.  Let me know if it looks okay.
>>
>> On the separate note, I need to think about that, I'm not sure I want to
>> complicate it further.
>>
>> Note you can export any variable automatically to the build environment
>> if it includes _PRECONFIG, _WANT_ or SYSCFG_ in the key name (see around
>> line 1599).
>>
>> Regards, Stuart
>> <preconfig_check.txt>
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]