Re: Quick test building a module cross all targets and architectures

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