From owner-freebsd-hackers Fri Jan 27 06:55:53 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id GAA18274 for hackers-outgoing; Fri, 27 Jan 1995 06:55:53 -0800 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id GAA18262 for ; Fri, 27 Jan 1995 06:55:50 -0800 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Fri, 27 Jan 1995 08:55:43 -0600 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Jan 1995 08:55:43 -0600 To: hackers@FreeBSD.org, freebsd-current@freefall.cdrom.com From: rkw@dataplex.net (Richard Wackerbarth) Subject: REMAKE WORLD Sender: hackers-owner@FreeBSD.org Precedence: bulk OK, guys! I'm on the "make" and I'm 'gonna take on the world. The warts on the makefile system have gotten out of control. It is time to throw out the old nag and get a fresh horse. I've "talked" to Jordan and we agree that this is a "good idea(tm)." Nothing is sacred. The plan: 1) Determine design goals 2) Design file structure to accomplish it. 3) Implement .mk files 4) Bring Makefiles into conformity. Although I have already given it some thought and think I have a good structure to accomplish it, we are just at step 1. Hopefully we can accomplish this for 2.1. If not, at least we can be well on the way. I'll start by throwing out a few ideas. Some of them may not fly, but that is OK. Right now, we need to decide WHAT rather than HOW. 1. The build procedure should run on any machine that meets certain minimal specs. (Like maybe 1.1.5.1) Doing a build will in NO way affect the host environment. 2. If everything is up to date, a make will do nothing except scan the tree. Nothing gets rebuilt unless it is out of date. 3. Build targets should exist for upgrading the running system, building a new root partition, and building tarball release files. Each of these would work off of the same object tree. 4. The make procedure is not allowed to "touch" it's input tree. The source tree can be read-only. The object tree can be read-only if up-to-date. 5. Multiple targets can co-exist at the same time. The entire process has a floating root. No path is hard coded. 6. Symbolic links are permitted. (This is a hard one because /../ does not necessarily get you back where you were :-( ) So much for starters. What other ideas do you want to throw in? 7. I know that we are not NetBSD but ... Multi-platform cross compiling is close enough to a fall-out that I think we should include the mechanism for it. 8. For those of us who build "sup -current" trees, the ability to post a "forget this program" lock which will allow a virtual delete of targets that do not properly build without altering the Makefiles.