From owner-freebsd-hackers Sat Jan 28 04:16:21 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id EAA17257 for hackers-outgoing; Sat, 28 Jan 1995 04:16:21 -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 EAA17251 for ; Sat, 28 Jan 1995 04:16:19 -0800 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Sat, 28 Jan 1995 06:11:08 -0600 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 28 Jan 1995 06:11:07 -0600 To: Bruce Evans From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: REMAKE WORLD Cc: hackers@FreeBSD.org Sender: hackers-owner@FreeBSD.org Precedence: bulk >>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. > >Too hard for 1.1.5.1. Require 2.1. Come now, 2.1 doesn't even exist. I can certainly set up a procedure that runs on a 2.0 system, and off hand, I don't see anything about 1.1 that precludes it. After all, what do we need? The ability to execute gcc, make, etc. There is nothing to say that these are the native versions. Remember, one of the goals is that we don't affect the running system. As a result, every reference MUST be to our own tree of {tools, sources, includes, libraries, objects, binaries, and installation} files. As long as we can compile the tools on a system, we can do it. I will make one concession. I will require the OS to support certain Unix commands and features. At this point, I don't know just what the minimal set is. I know MSDOS won't hack it because of file name problems, but I am not sure just how far back in Unix we need to go in order to run our tools. >>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. > >I have parts of this for 2.0. For `make; make install; make; make >install', the second make does nothing and the second install changes >very few timestamps although it is reinstalls almost everything. Gim'me! Gim'me! Assuming that you are willing to colaborate, my task may not be quite as hard. >This requires mainly not clobbering timestamps when installing unchanged >files. Making the world is harder, and most of the dependencies on >libc.a are bogus. Libc.a should not change if "make" does it's job properly. After all, what is magic about building a library? The output file depends on the objects just like any other part of the chain. If the library is up to date, make does nothing. >Links are normally done to ${SHLIBDIR}/libc.so.2.0. >These should be done to /usr/obj/lib/libc/libc.so.2.0, and the linkage >is not supposed to depend on the library file, only on the library >version. So we add shared library "cookies" that get changed only with the version number. >What is "nothing"? I'd like it to be nothing more than reading Makefiles >and stat()ing files to get timestamps. No building temporary files. I'd like that, too. >>5. Multiple targets can co-exist at the same time. The entire process has a >>floating root. No path is hard coded. > >This makes it hard to check out a single module outside of the source >tree and build it. It may be hard, but I don't really think impossible. Basically, you float EVERYTHING off of {SRCDIR}, {DESTDIR} type elements. >>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. >>6. Symbolic links are permitted. (This is a hard one because /../ does not >>necessarily get you back where you were :-( ) > >This is a bit inconsistent with (4). I think requiring obj links in the >source tree would be best. What is inconsistent? Obj links are not consistent with (5). ---- Richard Wackerbarth rkw@dataplex.net