On Tue, 2010-07-06 at 10:36 -0700, 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.
Newer versions of LTIB will look into the package directory to see if anything has changed, but I'm not certain that it works in all possible cases. If you make a change to rpm/BUILD/<package>, you can "./ltib -p <package> -m scbuild && ./ltib -p <package> scdeploy" to force a rebuild of just that package and then rebuild the rootfs.jffs2 resultant image incorporating that change (i.e. the "deploy" step will execute the %Install section of <packages> .spec file to copy <packages> created files into rootfs/), then run the deployment section to rebuild the resultant image.
But if you're just changing files in rootfs/ and want it to show up in the new rootfs.jffs2, then you can (if I understand things correctly) run "./ltib -p modeps -m scdeploy" to have LTIB rebuild the resultant rootfs.jffs2 from the rootfs/ directory content.
However, changes to the rootfs outside of a package should be done through the package .spec file that the file relates to. Then "./ltib" (if it understands that something has changed that requires it to do work) will rebuild/deploy that package, and if it did a build/deploy for any packages will re-run the post deployment (that builds the resultant image).
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.
LTIB does a few things. It looks at:
1) If a package .spec file changes
2) If SYSCFG_<package>* changed from a previous run
3) If any file in rpm/BUILD/<package> is newer than the .rpm created from a previous build of <pacakge>
4) For certain packages (kernel for example) if PKG_KERNEL_* changed from a previous build.
I'm sure there are more, but If any of the above are true, then LTIB rebuilds/deploys that pacakge. And of course if any package is re-deployed, then LTIB does the post-deployment step to rebuild the resultant image. Just a change to rootfs/ (outside of LTIB's operation) won't re-create the resultant image.
My understanding may be incomplete, but I think it should give you an idea of how LTIB triggers a build. You could grock "process_pkg_triggers" in the ltib perl script to understand more about the triggers. Hope this helps.
Charles
On Sun, Jul 4, 2010 at 9:02 PM, Peter Barada <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
http://lists.nongnu.org/mailman/listinfo/ltib