Date: Tue, 27 Oct 2015 09:38:44 -0600 From: Ian Lepore <ian@freebsd.org> To: Hans Petter Selasky <hps@selasky.org>, Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Quick test building a module cross all targets and architectures Message-ID: <1445960324.91534.84.camel@freebsd.org> In-Reply-To: <562F7577.7040804@selasky.org> References: <562DEE4F.5010203@selasky.org> <5888922.UHSgpdyTWY@ralph.baldwin.cx> <20151026182348.GT2257@kib.kiev.ua> <562F446E.6090906@selasky.org> <20151027121623.GW2257@kib.kiev.ua> <562F7577.7040804@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2015-10-27 at 14:00 +0100, Hans Petter Selasky wrote: > On 10/27/15 13:16, Konstantin Belousov wrote: > > On Tue, Oct 27, 2015 at 10:31:26AM +0100, Hans Petter Selasky > > wrote: > > > I understand that the compilation environments are different. > > > > > > How would you suggest to build-test a handful of C-files under a > > > single > > > device keyword and associated kernel module cross all kernels we > > > have in > > > a 10-minutes time-frame? MODULES_OVERRIDE can be defined from > > > within > > > kernel configs aswell, so possibly a MODULES_OVERRIDE_OVERRIDE is > > > needed > > > for this kind of feature. How about some kind of KERNCONF_APPEND= > > > parameter, which contains instructions for "config" to only emit > > > a > > > single device keyword, yet, keeping all options and parameters. > > > > Did you tried to pass > > -DNO_CLEAN -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND > > -DNO_KERNELOBJ > > options for make universe over the already built tree ? > > > > When I develop, I use > > make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG > > -DNO_KERNELDEPEND -DNO_KERNELOBJ > > unless I change config, or add a file, or add a module etc. This > > combination gives me seconds for whole kernel and modules rebuild > > time > > when I know that the build metadata, i.e. files participating in > > the > > build, and the build options, did not changed from the latest full > > rebuild. > > > > I think that a similar trick should work with make universe, it > > might be > > somewhat more involved to properly pass the directions, may be not. > > But > > it should give the build time in the range of tens of minutes, > > indeed. > > Hi Konstantin, > > You will need an initial complete universe build which compiles to be > able to use these options. > No, just a "make kernel-toolchains" which is noticibly faster than universe. You can add TARGETS=arm to get just the toolchains for the arm arches, or TARGET_ARCH=amd64 to get just that one arch. Building kernel toolchains for all arches means building clang many times, but it's something you only have to do a few times a year when a new version of clang is imported. > Not all C-files have a dependency rule, possibly due to a lack of > functionality in "config". I've burnt a few times with -DNO_CLEAN in > the > past because of "no-depend" keywords in sys/conf/files . > > In other words: > > make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG > > -DNO_KERNELDEPEND -DNO_KERNELOBJ > > Is not the same like: > > make buildkernel > > And especially before commit. > > The most promising in this thread so far is: > > make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules > > MODULES_OVERRIDE=foo Certainly it's *possible* to have a problem building kernels with NO_CLEAN, but IMO it's just not right to elevate that possibility into anything like a serious problem. I do NO_CLEAN builds literally dozens of times a day, across all arches. I can't remember the last time I had a problem. When it does cause a problem, or when I've made big changes that might require regenerating dependencies, I just rm -rf the kernel dir(s) within $OBJDIR and the next build takes 40 seconds instead of 7, or if doing all arch kernels and they're all removed, it takes maybe 15 minutes, but that's something I only do once every few weeks. BTW, MODULES_OVERRIDE on the command line already overrides the one in the config file. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1445960324.91534.84.camel>