hi guys,

I've suggested the following idea to a few people before,
and this thread seems like a good excuse to mention it again:

it seems to me that it would make more sense to do builds based on
$(MACHINE_ARCH) than on $(MACHINE), since the vast majority of the
files in a release are the same for (eg.) all 11 or 12 of the m68k
platforms.  the few programs that are really only relevant on one
particular $(MACHINE) (such as grfconfig, which is only useful on amiga)
could be built and installed on other systems anyway.   someday when
we move to the syspkg stuff then the installation process can allow
people to skip installing such files on systems where they aren't useful.

there are a few other issues with this kind of change:

 - header files that go in /usr/include/machine.
   most these are already common for all $(MACHINE)s of the same
   $(MACHINE_ARCH).  I suspect that many of the others can be merged.
   for files that exist for only one $(MACHINE), they can just be
   installed as-is.  I'm not sure there even exist any headers conflict
   in ways that matter for userland;  if any do exist, they would need
   to be resolved on a case-by-case basis.  a few years back matt thomas 
   had tried to have the arm ports /usr/include/machine point to "arm"
   instead of the individual $(MACHINE) dirs.  there were some problems
   with his implementation and it was taken out, but it would be good
   to think about how to make this idea work.

 - programs that have compile-time differences between $(MACHINE)s.
   these can be changed to determine $(MACHINE) at run-time, or via
   an argument if needed.  the merged /usr/sbin/installboot is a good
   example of this kind of thing.

 - boot loaders, boot blocks.
   build and install them all, have sysinst and other tools select
   the right one for the target hardware.

 - sysinst
   would need to be oriented around $(MACHINE_ARCH) as well.
   a given binary would need to know how to deal with all the
   $(MACHINE)s that it can run on.

 - release notes and other docs
   build and include them all in a release tree.

 - X server
   build and install them all, select which one to use at run-time.

 - kernels
   build them all and enable sysinst to select one that matches
   the hardware that it's running on.

 - build.sh
   would change from using "-m machine" to "-m machine-arch".


there are no doubt other issues that I haven't listed,
but hopefully this is a good basis for discussion.

I think this model would result in a much simpler release procedure.
for example, the business of verifing that (eg.) the all m68k
/usr/bin/ls binaries are identical would no longer be needed,
since we would only build one to begin with.

another advantage this would have for the project would be that
the auto-builds would happen much faster, since there would only be
10 or so releases to build instead of the current 40 or so.

-Chuck


On Thu, May 13, 2004 at 04:44:42PM +0200, Christian Limpach wrote:
> Hi,
> 
> From: "matthew green" <mrg@eterna.com.au>
> >    Log Message:
> >    ``build.sh -m xen-i386 release'' now builds a release for NetBSD/xen
> >    for i386.  The resulting release consists of:
> >    - NetBSD/xen for i386 kernel, loader and docuemntation
> >    - NetBSD/i386 userland sets
> >
> > if the userland is the same, is there any particular reason that
> > i386 can't just include a "xen" kernel?  eg, the way that sparc
> > includes a 32bit "sparc64" kernel.  see sparc/conf/GENERIC_SUN4U.
> 
> I'd actually prefer this since you install NetBSD/i386 first and then switch
> to the NetBSD/xen kernel.
> There might be 2 problems with this though:
> - if arch/i386/conf/GENERIC_XEN doesn't compile, release for i386 will fail
> - nothing will build the NetBSD/xen loader and documentation
> 
> > this would avoid having to have another port to "release".
> 
> I was thinking that we could maybe add a knob which prevents building the
> sets at all for build.sh -m xen-*.
> 
>     christian