Date: Tue, 24 Jan 1995 07:13:23 -0600 From: rkw@dataplex.net (Richard Wackerbarth) To: hackers@FreeBSD.org Subject: Make world Message-ID: <v02110106ab4aa76e2ddc@[199.183.109.242]>
next in thread | raw e-mail | index | archive | help
Personally, I feel that the "make" process is far from adequate. IMHO, I should be able to doo all of the following: 1) Compile a new system and make floppies, etc. for it on a running system WITHOUT altering the running enviornment of the host doing the work. 2) Alter some files in the tree and do a single "make all" at the top of the tree to recompile everything affected. 3) Not have "make all" ever do rebuilds if it follows another "make all" 4) (Eventually) Be able to cross compile for another type of system. 5) Be able to build similar kernels without having duplicate object modules. (Like "make links", but smarter -- IOW, folding of common options) Items 1 & 4 help "upgrade" from one release to the next. Items 2 & 3 reduce the "cost" of installing updates. Item 5 saves "time and space" There is still one problem for which I have no solution. This is caused by delays between updates and compiles. Assume that I have a correct source tree on day zero. On day two, I compile it and have a correct binary tree. All is well, so far. However, on day three, I learn that someone made a correction on day one. If I replace the source with one dated "3", make works just fine. However, my update procedure does not realize that I have the correct file. If instead, I replace the source with the one properly dated "1", make thinks that the binary (dated "2") is correct when, in fact, it is not. Is there any interest in modifying the system build procedure toward any of the goals mentioned? If so, I am willing to help. Does anyone have a good solution to the synchronization problem?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02110106ab4aa76e2ddc>