Re: [Ltib] Understanding ltib initialization

[Stuart Hughes]

Hi Charles,

Peter has answered most of this.  Just to clarify (it does a bit more,
but this is the most important):

1. If you change a file in rpm/BUILD/_some_package_ and run ./ltib, it
should notice and re-built that package and re-install into the rootfs/*
area.  Other dependency re-builds could be triggered.  In your case if
anything builds in rpm/BUILD/linux/ then the uImage should get re-built
and re-installed.

2. If any package changes, then the image (jffs2 etc) gets re-built

3. If you change anything in rootfs/* by hand, nothing will happens as
far as ltib is concerned as this is an output area.

Regards, Stuart

Charles Krinke wrote:
> Dear Peter and Stuart:
> 
> Thank you for your kind replies. This helps put it together a bit more
> in my mind. I would like to ask another question if I may.
> 
> First, I am trying to build a uImage and a rootfs.jffs2 on a regular
> basis as I work through some bugs. This necessitates building uImage and
> rootfs.jffs2 several times a day. I end up running "./ltib -c" because
> when I change a file in the linux directory *or* add a file to the
> rootfs/ directory, running ltib does not *always* build the kernel or
> root filesystem images. My assumption is that ltib depends on Makefile
> logic for uImage so should build whenever a file known to a Makefile in
> the kernel tree changes. I do not yet know how ltib determines when it
> should build a new rootfs.jffs2.
> 
> So, with that said, would you mind describing a bit more in detail how
> ltib *knows* when to build a uImage and a rootfs.jffs2? Perhaps if I
> understood a bit more of ltib's dependency tree I could figure this one out.
> 
> Charles
> 
> On Sun, Jul 4, 2010 at 9:02 PM, Peter Barada <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     On Sun, 2010-07-04 at 13:25 -0700, Charles Krinke wrote:
>>     Dear Sirs:
>>
>>     I have inherited a project using ltib and have studied and
>>     understood some of it, but there are some holes in my knowledge. I
>>     wonder if someone could help me out with a few clues by answering
>>     these questions.
>>
>>     1. When ltib starts up, what files does it use? Just .ltibrc or
>>     others?
>     That and others.  First, ltibe looks into .ltibrc to find
>     information about where bits are, how to access stuff, etc.
>     Then it looks in .config to find the platform directory to use, then
>     in that platform direcotry (config/plaforms/<platform>), it looks
>     for .config then defconfig.dev, then defconfig to find the
>     configuration that describes which packages to build (and which
>     configuration bits for those packages).
> 
> 
>>     2. I find that each time I run ltib, I need to run "ltib -c" and
>>     reselect all my target parameters. Where does ltib store (and
>>     read) its configuration file from when one runs "ltib" or "ltib -c".
>     You shouldn't have to run "./ltib -c" - "./ltib" should build what
>     you need unless you need to change a configuration item.  ltib
>     update config/plaform/<platform>/.config and
>     config/platform/<platform>/defconfig.dev with any configuration
>     changes.  Are you trying to do a configuration change outside of
>     ltib?  If so then it may not get picked up until you do "./ltib -c".
> 
>>     3. I am having trouble consistently building uImage and
>>     rootfs.jffs2. Can someone help me understand a recipe to
>>     consistently build both? Although I can run "ltib -m shell", I get
>>     stuck on it wanting a single package. Is there a way to just build
>>     a uImage and a rootfs.jffs2 from the "ltib -m shell" ??
>     You can't build a full image from "./ltib -m shell" - that's only
>     used if you need to do something outside the ordinary (i.e. just
>     build a kernel by "cd rpm/BUILD/<linux-build-directory> && make
>     ARCH=arm 'HOSTCC=ccache /usr/bin/gcc -B/usr/bin//' uImage && scp
>     arch/arm/boot/uImage <user>@<target-IP>/tftpboot/" for an arm kernel
>     that you can then load on your target with u-boot, but until you've
>     worked with LTIB long enough, using "./ltib -m shell" can be
>     haxardous to your work".
> 
>     If your project is properly set up(and configured), then "./ltib"
>     should just build what you want, leaving the rootfs/directory with
>     components you can copy over to either burn or load on the target
>     and run with....
> 
>     What specifically are you doing that requires continually doing
>     "./ltib -c" and reselecting all the components you need?
> 
>>     Charles
>>     _______________________________________________
>>     LTIB home page: http://ltib.org
>>
>>     Ltib mailing list
>>     address@hidden <mailto:address@hidden>
>>     http://lists.nongnu.org/mailman/listinfo/ltib
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> LTIB home page: http://ltib.org
> 
> Ltib mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/ltib