At Wed, 16 Nov 2011 19:20:46 +0000 (UTC), christos%astron.com@localhost
(Christos Zoulas) wrote:
Subject: Re: NetBSD cross tools
>
> In article <rmimxbwc9fs.fsf%fnord.ir.bbn.com@localhost>,
> Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
> >-=-=-=-=-=-
> >
> >
> > christos%astron.com@localhost (Christos Zoulas) writes:
> > >
> > > Use the nbmake-<arch> make wrapper.
> >
> > That only works for things that use BSD make; it doesn't provide a
> > generic cross environment for random third-party code.
> >
> > Also, it doesn't support three simultaneous destdirs, one for NetBSD
> > proper, one for pre-built binary packages for pkgsrc, and one for the
> > other code being built directly out of a version control system
> > checkout.
> > One can't drop random files in the NetBSD DESTDIR, since then checkflist
> > fails on the next build.
>
> We could provide wrappers that do all those, it is not too difficult.
Indeed! But.... Maybe there's an even better way! :-)
I've been thinking about this off and on for some time, ever since I
built my first totally-crunch-gen'ed system.
Actually I've talked about this for years now, but from a slightly
different angle.
The idea is basically that if we were to make the Makefiles properly and
solely authoritative for everything then checkflist and all the manually
maintained sets lists, etc. all just go away -- vanish completely; and
maketars is simplified considerably and then fed by much simpler dynamic
list building mechanism which is entirely driven by the Makefiles which
actually build and install everything in the first place. Indeed
everything could be triggered by install's "metalog" if it were given
one additional parameter: set-name.
I.e. if it gets built and installed, and thus is listed in the metalog,
then it gets put into a (Makefile-specified) set automatically.
Now variables in the Makefiles, set in mk.conf for example, can totally
control what's included in a "distribution", and indeed with care in how
the dependencies between these variables are defined different forms of
distributions can all be built from DESTDIR and the metalog alone.
It also makes it entirely trivial to add a list of one or more
directories containing "local" sources (and NetBSD-compatible Makefiles)
which will then be built, installed, and included in the distribution(s)
(including whether they go in a separate tar set, or which "native" set
they are included in, etc.).
All driven from the Makefiles -- the one true source of authority for
what gets built, what gets installed, and where it goes in the
distribution(s).
It also makes some other kinds of local modifications very trivial. If
someone wants to mix everything into one /bin (e.g. get rid of /usr :-))
or even just move one or two things they think are more critical into
/bin (e.g. awk), then only one Makefile need be modified (a Makefile.inc
in the case of the first example).
I've always hated the sets lists, and my ideas of how to get rid of them
were just forming when the metalog thing came along and made my ideas
even simpler to implement, but unfortunately I never got around to
actually writing anything more formal than an e-mail like this, or
trying to implement them on my own, etc.
Somewhere along this path I'd also like to figure out some way to be
able to integrate a simple on/off switch in the build so that everything
could be static-linked into one crunchgen binary, and possibly even a
simple way to add this alongside a traditional multi-binary build.
I.e. some way to also (dynamically) build one, or several variants, of
the LISTS file(s) (for Makefile.ramdisk). Then it would be just as
trivial to create embedded systems with any mk.conf options, including
local add-ons.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgppmLi6BmwF5.pgp
Description: PGP signature