ltib
[Top][All Lists]
Advanced

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

Re: [Ltib] Special tag localdir_nobuild causes LTIB to go to the confi


From: aaron
Subject: Re: [Ltib] Special tag localdir_nobuild causes LTIB to go to the config screen.
Date: Mon, 30 Nov 2009 15:59:25 -0600
User-agent: SquirrelMail/1.4.19

Hi Stuart.  I know this thread is from a while ago, and that this is
probably a minor issue.  I just thought I'd mention that I think it might
be more correct to avoid clearing these transient configuration flags
(*WANT_CF and *LEAVESRC) when constructing a release or test release BSP.

The thing is that even if I have a "select PKG_KERNEL_LEAVESRC" line
somewhere, or otherwise have it configured, it will get cleared with the
"./ltib -m clean" line in bin/Ltibrelease.pm when building a release.  Now
that the fix we worked on is present, the localdir_nobuild tag happily
does not clear the transient flags automatically, but other tags such as
localdir will.  This means that the configuration used to construct the
BSP will differ from the configuration of the BSP when it's being
installed from the iso (if any of the *WANT_CF or *LEAVESRC flags are set
to 'y' in the default configuration) for all release tags except
localdir_nobuild, and I think this is a little inconsistent.  I believe
that the configuration that is present at the time the iso BSP is being
built should be the equivalent configuration when the iso BSP is being
installed.

Particularly bad is the way the localdir special tag is working right now.
 Since I have a kernel module that depends on the kernel sources being
unpacked, I have my select PKG_KERNEL_LEAVESRC line in the package.lkc.  I
go to make a test release, and this builds the kernel binary RPM as
expected, but after it's built, the LTIB script clears
CONFIG_PKG_KERNEL_LEAVESRC in the .config file that is distributed with
the BSP.  When the user goes to install the BSP from the iso with "cd
non-*; ./ltib", the kernel package is actually automatically rebuilt
because there is a file .config.old that has CONFIG_PKG_KERNEL_LEAVESRC=y,
and this differs with the .config file.  So, in effect, it rebuilds the
kernel binary RPM unnecessarily, but on top of that, it clears the kernel
source when it's finished, because in the new .config file
CONFIG_PKG_KERNEL_LEAVESRC is not set.  Supposing a user wants to force a
rebuild of the kernel module at this point, the kernel source will not be
available in the BUILD directory.

Perhaps it might work for only the "./ltib -m clean" operation to avoid
clearing transient flags, and then these flags will persist through this
call, and be present in the same state in the BSP as they were to build
the BSP.

What do you think?

Aaron

> Hi Aaron,
>
> PKG_KERNEL_LEAVESRC is meant to be a one-shot as once unpacked the
> source will remain and so there's no need to keep the flag enabled.
>
> If you package needs the kernel source unpacked it should be selecting
> PKG_KERNEL_LEAVESRC rather than relying on manually setting this in the
> ./ltib -m config session.  Take a look at config/userspace/package.lkc,
> for example:
>
> config PKG_HELLOWORLD_MOD
>      depends CAP_HAS_MMU
>      select PKG_KERNEL_LEAVESRC
>      bool "hello world module example"
>      help
>          simple hello world kernel modules example
>
> Regards, Stuart
>
>
> address@hidden wrote:
>> Hi Peter and Stuart.  Working with my kernel module is precisely where
>> this gave me a little trouble.  I understand that you need the kernel
>> source unpacked for a kernel module package.  My question was why this
>> is
>> a one-shot or transient variable.  The area that it was giving me a few
>> problems was after creating an iso release, the build and installation
>> of
>> the BSP onto another machine.  Using `./ltib` I would attempt to build
>> the
>> whole project (host and target packages), and I would get stuck on the
>> kernel module package because my kernel source would not remain in the
>> BUILD directory.  This was because the PKG_KERNEL_LEAVESRC=y that I had
>> put in place earlier was getting cleared automatically by a call to
>> `./ltib` when building the iso.  Since I was running into this sort of
>> problem, I was wondering if there is any beneficial reason for having
>> the
>> LEAVESRC variable as a one-shot or transient variable.  It seems like if
>> you have the source out for a particular package, and then you wanted to
>> get rid of it, you can just remove it, and change the configuration to
>> comment out any variables like PKG_KERNEL_LEAVESRC if necessary.
>> Updating
>> the date/time stamp on my config/platform/${board}/.config file does not
>> force a rebuild of the kernel for me.
>>
>>> One to thik about is a seperate package that builds a kernel module
>>> (like PKG_HELLO_WORLD_MOD).  It needs the kernel source to remain so it
>>> can use the kernel build structure/headers to create a module that is
>>> loadable by the kernel....
>>
>>
>>> Hi Aaron,
>>>
>>> Once source code is blown out and left (with LEAVESRC) it will stay
>>> there. nothing will remove it until you do manually, so the flag only
>>> needs to be transient.  The need for this is as Peter says, some
>>> packages (like kernel modules) need access to the the real built kernel
>>> sources.
>>>
>>> --leavesrc --force should leave all the sources unpacked.  This is
>>> generally speaking a bad idea.
>>>
>>> Thanks for the patch.
>>>
>>> Regards, Stuart
>>
>>
>>
>>
>> _______________________________________________
>> LTIB home page: http://ltib.org
>>
>> Ltib mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/ltib
>>
>







reply via email to

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