[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Heads up, changes to modules/exec/etc, note for portmasters/developers
> > Would not this make it essentially impossible to build a compat_16
> > module which is processor-variant-neutral? Or... one that will work
> > at all on any of these variants by default...?
> I think processor-variant-neutral might be difficult to achieve generally.
> It's not technically difficult but is laborious, especially because of the
> number of ports, and needs someone with interest to work on it. We key on
> $MACHINE for the module build/install/etc. I wonder if this might be
> problematic due to shared base.tgz?
> It can be done for xen/x86 because there is someone interested and the
> differences are few in number.
Hmm... For evbppc there appears to be the following existing
combinations of cpu variants and interrupt variants:
oea + marvell
oea + pmppc
ibm4xx + ibm4xx
I'm wondering if a combination of modifying what module loads key off
for the evbppc port and "build same tree multiple times with different
settings" a'la netbsd32 would be a viable route to follow.
However, this does not deal with the "does it have altivec" variation
which one might stumble across within the oea series (e.g. g3 vs. g4),
perhaps that variation needs to be dealt with in a different manner?
> > While on the subject of build-breakage for the powerpc ports, the
> > evbppc port is also in that group because it attempts to build modules
> > which end up including machine/intr.h (because _KERNEL is defined),
> > which contains
> > #include PPC_INTR_IMPL
> > and that macro is not defined in a module build.
> Hmm, see this:
> Do you see it trying to build them?
Main Index |
Thread Index |