Date: Tue, 4 Apr 1995 21:23:21 -0500 From: rkw@dataplex.net (Richard Wackerbarth) To: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com, nate@trout.sri.MT.net Cc: "Jordan K. Hubbard" <jkh@freefall.cdrom.com> Subject: NOTICE: If you care, speak now! Message-ID: <v02120b08aba77e0068f0@[199.183.109.242]>
next in thread | raw e-mail | index | archive | help
I WANT to make a significant change to the way new systems get built. The purpose is to reduce unnecessary recompilations, allow read-only source trees, and prepare for cross-compilation. Is this something that the community will accept? Your support or opposition is requested. Silence will be considered acceptance. I have a structure that will allow: The "upside": 1) The environment of the host system is NOT disturbed by the "making" of a new release. 2) The source and object files MAY be shared by multiple releases without impacting each other. 3) The tree MAY be on read-only media. If you wish to change only a part of the tree, only the affected parts need be on writeable media. 4) Redundant compiles are eliminated. "make all" folled by a second "make all" will not cause anything to be recompiled. (The compressed man pages are another, but related, issue) The "downside": 1) To build a new kernel, etc. you must place it in a proper "tree" structure. That tree can be rooted anywhere you wish. ( This could be handled by a script or possibly special "make" targets.) 2) Unless you are in a "proper" tree, you must either do a make from the root of the tree OR predefine the TREE environmental variable. An "aside": The default behavior would be for a proper tree rooted at /usr. In this case, the behavior would be sililar to the current operation. "Obj" links could optionally be added and would work IF you have only one version of the tree. They would be "for reference only" and not used to build the system. =============== PROPOSED PLAN OF ATTACK For this to happen, I will require the cooperation of ALL comitters. We will need a "standard" for "correct" Makefiles. Once it is determined, anyone who changes a Makefile would make the alterations to meet the specification. In order to implement this, I propose 1) By Thursday, I will distribute a proposed "standard" for the make files. 2) By Monday, we will agree to the standard. 3) I'll make changes to the .mk files to make them accept both the present Makefiles as well as those that conform to the new standard. 4) Over some period (depending on complexity/manpower) we convert ALL Makefiles to the new standard. 5) I then commit new .mk files which implement the new structure. ================= OK, gang, I've "argued" this for a few days. So far, I have heard from only a very few. Garrett "objects", but has not stated ANY reason. Nate and Rodney seem to think it won't work, but only because they think that Genassym is "special". I interpret their comments as "It's OK if it doesn't break anything". Rodney writes: >Drop this issue for now, until you have actually made what you are >saying work. It DOES work if you allow me my TREE variable (or require that I cd there to type "make"). Just remember that genassym is a "tool" and gets made in the tool environment which would be the same as /usr except that I prefer to indirect it one level so that I don't clobber a "good" version of a tool with a bad one that I just modified. Nate writes: >1) Is really any better than what we have for the majority of the users. It does not affect most "users". It only changes the "standard" by which "conforming" Makefiles are written and the .mk files to support them. >2) Is it feasible? Only it there is an authority that can reject Makefiles that do not conform to the agreed standard. >3) Will you do all the work required to make it work right I already have done much of it on my own system. The problem is that there was too much "I don't want to do it that way" for me to feel that this group could reach ANY standard. The entire Make system NEEDS to be redone. The warts have overwelmed the substance. Everyone would benefit from a cleaner system. "Make world" would become much faster because we have not yet gotten to the case of true cross compilation. There is a lot of unnecessary duplication because the source tree is being used to make both tools and a target when they are, in fact, the same. ---- Richard Wackerbarth rkw@dataplex.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02120b08aba77e0068f0>