From owner-freebsd-current@freebsd.org Tue Oct 27 09:29:50 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 AD560867F for ; Tue, 27 Oct 2015 09:29:50 +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 6B5461263 for ; Tue, 27 Oct 2015 09:29:49 +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 83EB11FE023; Tue, 27 Oct 2015 10:29:41 +0100 (CET) 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> Cc: freebsd-current@freebsd.org From: Hans Petter Selasky Message-ID: <562F446E.6090906@selasky.org> Date: Tue, 27 Oct 2015 10:31:26 +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: <20151026182348.GT2257@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 09:29:50 -0000 On 10/26/15 19:23, Konstantin Belousov wrote: > On Mon, Oct 26, 2015 at 11:03:07AM -0700, John Baldwin wrote: >> On Monday, October 26, 2015 10:11:43 AM Hans Petter Selasky wrote: >>> Hi, >>> >>> We have NO_MODULES for building kernel without modules, but no NO_KERNEL >>> to only build the modules. >>> >>> What do you think about the following patch: >>> >>>> diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk >>>> index ddf828e..f0920df 100644 >>>> --- a/sys/conf/kern.post.mk >>>> +++ b/sys/conf/kern.post.mk >>>> @@ -32,7 +32,11 @@ KERN_DEBUGDIR?= ${DEBUGDIR} >>>> >>>> .for target in all clean cleandepend cleandir clobber depend install \ >>>> obj reinstall tags >>>> +.if !defined(NO_KERNEL) >>>> ${target}: kernel-${target} >>>> +.else >>>> +${target}: >>>> +.endif >>>> .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && exists($S/modules) >>>> ${target}: modules-${target} >>>> modules-${target}: >>> >>> It allows only a single module with MODULES_OVERRIDE= and NO_KERNEL=YES >>> to be built with universe in very little time. This can save a lot of >>> build time when changes are limited to a set of kernel modules. >> >> Can you just use something like MODULES_WITH_WORLD instead? >> >> make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules MODULES_OVERRIDE=foo >> >> (If it's only 1 module directory you can probably just use SUBDIR_OVERRIDE directly?) >> >> make tinderbox MAKE_JUST_WORLDS=yes SUBDIR_OVERRIDE=sys/modules/foo >> > > In any variant, this proposal sounds strange. Almost all in-kernel > code is compiled both for kernel and for modules. I am only aware of > exceptions for i915kms, which was done for a reason which is no longer > valid. In other words, if your goal is to check that the change does not > break compilation of some kernel code, then it is wrong to not compile > kernels. > > Note that kernel and modules compilation environments are differrent. > Hi, 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. --HPS