Date: Mon, 20 Jun 2005 12:56:07 -0700 From: Bakul Shah <bakul@BitBlocks.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: rwatson@freebsd.org, current@freebsd.org Subject: Re: dhclient less functional with nanobsd because of NO_CXX Message-ID: <200506201956.j5KJu7db084244@gate.bitblocks.com> In-Reply-To: Your message of "Mon, 20 Jun 2005 12:49:05 MDT." <20050620.124905.35871665.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> It is generally desirable to have a separate 'install' environemnt > from the 'build' environment on real embedded systems. The fact that > nanobsd doesn't have this useful distinction is a problem with > nanobsd, not devd. It should build everything, but install with all > the NO_XXX flags set to do subsetting. would it make sense to use an mtree file as a starting point particularly for embedded systems? perhaps a tool that takes output of make -n install + an mtree description of a system and spits out which install targets need to be built. the basic problem in my view is that install targets don't quite fit in the `make' model of maintaining a dependedancy graph -- make install sends thing *outside* the source tree that make manages. the same is true of various other 'magic' targets since make is being used as a swiss-army-knife, perhaps mtree should be extended to specify where to pick things up in order to populate a target tree. then one can periodically do something like `mtree --update sys.mtree' and have it build *eveything* that changed since the last time you did this operation _and_ save a snapshot so that you can get back to a previous consistent snapshot. for what it is worth.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506201956.j5KJu7db084244>