Thanks, that would be great. Peter Barada <[email protected]> wrote:
>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
