From owner-freebsd-current@freebsd.org Tue Oct 27 12:58:57 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 14C40A1E73C for ; Tue, 27 Oct 2015 12:58:57 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 C84A21E03 for ; Tue, 27 Oct 2015 12:58:56 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A4DCE1FE023; Tue, 27 Oct 2015 13:58:54 +0100 (CET) From: Hans Petter Selasky Subject: Re: Quick test building a module cross all targets and architectures To: Konstantin Belousov References: <562DEE4F.5010203@selasky.org> <5888922.UHSgpdyTWY@ralph.baldwin.cx> <20151026182348.GT2257@kib.kiev.ua> <562F446E.6090906@selasky.org> <20151027121623.GW2257@kib.kiev.ua> Cc: freebsd-current@freebsd.org Message-ID: <562F7577.7040804@selasky.org> Date: Tue, 27 Oct 2015 14:00:39 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151027121623.GW2257@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed 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 12:58:57 -0000 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. 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 --HPS