Date: Tue, 28 Aug 2012 17:28:15 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Jamie Paul Griffin <jamie@kode5.net> Cc: freebsd-stable@freebsd.org Subject: Re: Question About Tracking the Stable Branch Message-ID: <alpine.BSF.2.00.1208281713180.81894@wonkity.com> In-Reply-To: <20120828223413.GB78518@kontrol.kode5.net> References: <20120828203130.GB78051@kontrol.kode5.net> <CAN6yY1tKTu2mRaDo1WyNtvv7Sw5yFuTrru2QyGvD8jQg1oZ%2BPw@mail.gmail.com> <CAOjFWZ7HM2Z4FqPeoJ2c1qbX1DaygGGg5CLJh%2BytDs4wjBfVFg@mail.gmail.com> <20120828223413.GB78518@kontrol.kode5.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Aug 2012, Jamie Paul Griffin wrote: > I've always updated my -RELEASE systems using the traditional method > so it seems it's no different other than perhaps updating more > frequently and deciding whether or not both kernel code and userland > code needs to be rebuilt together. > > It certainly seems a bad idea for me as someone with a lot to learn, > to patch specific parts of the source tree and rebuild those parts as > something is bound to go wrong at some point for me. In addition to what others have suggested, the devel/ccache port can seriously reduce world and kernel compilation time by caching results. Stuff that hasn't changed comes out of cache rather than from a recompile. A buildworld every few days usually takes only about a fourth of the time it would take without ccache. Unfortunately, so far it only has this extreme an effect with gcc, not so much with clang. I usually use 4G of cache space; haven't tested to see how much is actually needed. Setting CCACHE_COMPRESS=yes fits more files in the cache. In my tests, there was no speed penalty.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1208281713180.81894>