Re: CVS commit: src/tests

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

pooka%NetBSD.org@localhost wrote:

> On Tue Dec 09 2008 at 12:54:26 +0100, Juergen Hannken-Illjes wrote:
> > On Mon, Dec 08, 2008 at 12:39:04PM +0000, Antti Kantee wrote:
> > > 
> > > Module Name:      src
> > > Committed By:     pooka
> > > Date:             Mon Dec  8 12:39:04 UTC 2008
> > > 
> > > Modified Files:
> > >   src/tests: Makefile
> > > 
> > > Log Message:
> > > Don't descend into modules on evbppc.. sigh
> > 
> > It is not that simple :-)
> > 
> > The corresponding PR is 39996, building evbppc now yields:
> > 
> > ======  5 missing files in DESTDIR  ========
> > Files in flist but missing from DESTDIR.
> > File wasn't installed ?
> > ------------------------------------------
> > ./usr/tests/modules/Atffile
> > ./usr/tests/modules/k_helper
> > ./usr/tests/modules/k_helper/k_helper.kmod
> > ./usr/tests/modules/t_modctl
> > ./usr/tests/modules/t_modload
> > ========  end of 5 missing files  ==========
> 
> sigh_level > sigh_max
> 
> At least it builds now, so I'll not revert this for the time being.

You can simply move these entries from distrib/sets/lists/tests/mi
to module.mi.

> IMHO evbppc should be split if the supported cpus are that different.
> (Or maybe we should combine i386 and vax so that evbppc doesn't feel
> lonely ;)

evbppc isn't alone. I doubt sun3 modules will work both on sun3 and sun3x.
(and I guess all evb* ports have the similar problems)

In general, if single ${MACHINE} requires multiple GENERIC-like kernels
to support multiple machines, we also have to provide multiple modules
for each variant. They might require different static parameters
in their kernels.

For now, it's acceptable for me to simply disable modules on such ports.
---
Izumi Tsutsui