From owner-freebsd-arch  Sun Feb 18  1:20:23 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229])
	by hub.freebsd.org (Postfix) with ESMTP id F2E4A37B491
	for <arch@FreeBSD.ORG>; Sun, 18 Feb 2001 01:20:20 -0800 (PST)
Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1])
	by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1I9JdH11289;
	Sun, 18 Feb 2001 01:19:39 -0800 (PST)
	(envelope-from jkh@winston.osd.bsdi.com)
To: Warner Losh <imp@harmony.village.org>
Cc: "Daniel C. Sobral" <dcs@newsguy.com>,
	Mark Murray <mark@grondar.za>, arch@FreeBSD.ORG
Subject: Re: Moving Things [was Re: List of things to move from main tree] 
In-Reply-To: Message from Warner Losh <imp@harmony.village.org> 
   of "Sun, 18 Feb 2001 02:02:22 MST." <200102180902.f1I92MW01403@harmony.village.org> 
Date: Sun, 18 Feb 2001 01:19:39 -0800
Message-ID: <11284.982487979@winston.osd.bsdi.com>
From: Jordan Hubbard <jkh@winston.osd.bsdi.com>
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> 	I'd like to point out that making FreeBSD more modular doesn't
> necessarily mean that we have to change the policy we have hard coded
> into the Makefiles.  We can and do subset things more easily than

Absolutely, we're in violent agreement on that point.  I'm just
suggesting that instead of having the policy be represented by
SUBDIR lines in Makefiles, it should instead be something like
this:

<?xml version="1.0"?>
  <list>
    <target>FreeBSD-standard</target>
    <tag>RELENG_4</tag>
    <desc>This is what constitutes the "standard" version of FreeBSD<desc>
    <sub-targets>
	bin
	lib
	usr
	etc
	installer
     </sub-targets>
   </list>

And when I say something "like" that I'm really reaching because this
is a seriously contrived example which doesn't even begin to enumerate
all the various types of meta-data which one would need to describe
"the standard release of FreeBSD."  I'm not even saying it would be in
XML (please put those spears down), only that it would live outside of
the actual build mechanism and simply become configuration data.

Such a thing would also finally get rid of all those evil and
not-very-comprehensive NO_FOO variables in the source tree, as if
any of us truly needed to see a list of our current build system's
shortcomings.

And yes, I do also realize that coming up with something even half as
sophisticated as what I've described so far will take more than lots
of mere hand-waving on the subject.  Progress often moves in strange
ways, so let's just see where all this goes.

- Jordan


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message