On 02/16/2012 03:08 AM, Stuart Hughes wrote: > Maybe the best thing would be to allow this per project using a setting in > the .ltibrc file. That way a user would knowingly turn off clobber > protection. That would work perfectly!
Then if someone tries using --clobber w/o the appropriate flag set in .ltibrc it will ignore it (and spit out an appropirate message). I'll code something up against the current LTIB and send it out. > Peter Barada <[email protected]> wrote: > >> On 02/15/2012 05:01 AM, Stuart Hughes wrote: >>> Hi Mike, >>> >>> The philosophy is that unpacked source is never clobbered. >>> >>> To do what you want, you would be better to have your kernel source code >>> outside ltib (under git control etc). >>> >>> To do this, run ./ltib -m config and under "choose your kernel", select >>> "Local Linux directory build", you can then point ltib to use your SCM >>> control kernel tree. When you're done, you can roll it up (as a patch >>> against the original or whatever makes senses). >> Stuart, that works only for the kernel, not if there at inter-package >> dependencies _outside_ of the kernel. >> >> Mike, I've gone through this before when setting up buildbot to create >> images as a front end for an automated test system and ran into your >> _exact_ problem. In my case I have a OMAP wl12xx WiFi driver/utility >> package that needs access to openssl and wpa_supplicant _source_ to >> build as it uses internal functions from those packages (I wouldn't have >> written it that way but its what I'm stuck with). >> >> To solve this problem for automated builds using buildbot, I added a >> "--clobber" option to LTIB that removes a package's build directory if >> the packages .spec file changes. The changes are pretty minimal; see >> this thread: >> >> http://lists.gnu.org/archive/html/ltib/2011-01/msg00055.html >> >> Stuart, I understand the philosophy that unpacked source is never >> clobbered, but in my/Mike's case where we are trying to use LTIB in >> continuous integration systems, there is a need to be able to do this in >> an automated manner, and "--clobber" is about the best I can think of... >> >>> Regards, Stuart >>> >>> On 15/02/12 00:00, Mike Goins wrote: >>>> Wondering if anyone else has this particular type of situation. >>>> >>>> I setup a continuous integration system involving ltib. ltib also >>>> builds kernel modules outside the source tree, so I have >>>> PKG_KERNEL_LEAVESRC=y so the modules can build. But when the kernel >>>> spec is updated, ltib refuses to colbber the existing kernel build >>>> directory and apply the updated spec (usually new patches). >>>> >>>> I guess what I would like is if the the spec file is updated and ltib >>>> detects a "directory build", is to go ahead and automatically clobber. >>>> Now sure where I can make this modification to ltib. Or is there >>>> some other way to accomplish this? >>>> >>> _______________________________________________ >>> LTIB home page: http://ltib.org >>> >>> Ltib mailing list >>> [email protected] >>> https://lists.nongnu.org/mailman/listinfo/ltib >> >> -- >> Peter Barada >> [email protected] >> >> >> _______________________________________________ >> LTIB home page: http://ltib.org >> >> Ltib mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/ltib -- Peter Barada [email protected] _______________________________________________ LTIB home page: http://ltib.org Ltib mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/ltib
