Date: Fri, 27 Jan 1995 08:55:43 -0600 From: rkw@dataplex.net (Richard Wackerbarth) To: hackers@FreeBSD.org, freebsd-current@freefall.cdrom.com Subject: REMAKE WORLD Message-ID: <v02110112ab4eb04f4245@[199.183.109.242]>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02110112ab4eb04f4245>