From owner-freebsd-current@freebsd.org Tue Oct 27 15:38:54 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CB4EA1F629 for ; Tue, 27 Oct 2015 15:38:54 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E446F1B79 for ; Tue, 27 Oct 2015 15:38:53 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 27 Oct 2015 15:39:08 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t9RFcitP030069; Tue, 27 Oct 2015 09:38:45 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1445960324.91534.84.camel@freebsd.org> Subject: Re: Quick test building a module cross all targets and architectures From: Ian Lepore To: Hans Petter Selasky , Konstantin Belousov Cc: freebsd-current@freebsd.org Date: Tue, 27 Oct 2015 09:38:44 -0600 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> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 15:38:54 -0000 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