From owner-freebsd-current@FreeBSD.ORG Mon Jun 20 19:56:11 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5753E16A41F; Mon, 20 Jun 2005 19:56:11 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3174043D1F; Mon, 20 Jun 2005 19:56:10 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.3/8.13.1) with ESMTP id j5KJu7db084244; Mon, 20 Jun 2005 12:56:07 -0700 (PDT) (envelope-from bakul@bitblocks.com) Message-Id: <200506201956.j5KJu7db084244@gate.bitblocks.com> To: "M. Warner Losh" In-reply-to: Your message of "Mon, 20 Jun 2005 12:49:05 MDT." <20050620.124905.35871665.imp@bsdimp.com> Date: Mon, 20 Jun 2005 12:56:07 -0700 From: Bakul Shah Cc: rwatson@freebsd.org, current@freebsd.org Subject: Re: dhclient less functional with nanobsd because of NO_CXX X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2005 19:56:11 -0000 > 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.