Date: Thu, 20 Jul 1995 19:23:10 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: asami@cs.berkeley.edu (Satoshi Asami) Cc: hackers@freebsd.org Subject: Re: Strange entries in /usr/src/Makefile Message-ID: <199507210223.TAA10403@gndrsh.aac.dev.com> In-Reply-To: <199507210123.SAA03025@forgery.CS.Berkeley.EDU> from "Satoshi Asami" at Jul 20, 95 06:23:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > * I can not go with nuking them, some sites have become acustom to > * what we have. > > That's true, but we need to try to clean up our source tree once in a > while, and /usr/src/Makefile is already 300+ lines long. If it isn't > used that much and this can be changed without much pain (how many > sites are actually using them?), I think we should nuke it. Browsing > through /usr/src/Makefile is already enough pain without this. ;) If you think /usr/src/Makefile is complicated, go read release/Makefile for some enjoyment... Or how about this for a comparitive, the length of bsd.port.mk is almost as long as the sum of all the other .mk files combined :-) File length is a pretty meaningless metric. Building the src tree is a complicated process. Removing 6 lines in 300 is insignificant. > * Perhaps the default value of > * PORTSDIR should move to a more visible location. > > That's an idea, we can put it in /etc/make.conf 'cause then anything > can pick it up. If it's really necessary, that is. /etc/make.conf would probably be the right place, it is a per site type of value. > * Your missing a lot of the context and everything that went into > * the initial work to put that stuff in there, this was not just > * some half cocked lets go off and add this. It was discussed and > * reviewed, changed and envolved for about a 2 week period before > * it ever got added. > > I did look at the cvs log even before I sent out the original > message. I couldn't find anything there, so I assume it went in > before the 4.4 switch, is this correct? Yes, it did, here is some of the rcs log that effected the change: ---------------------------- revision 1.33 date: 1994/01/26 03:50:15; author: rgrimes; state: Exp; lines: +9 -1 I cleaned this up and applied it. >From: Julian Howard Stacey <stacey@guug.de> Subject: patch for src/Makefile as find obj on local & ports failed Date: Mon, 24 Jan 1994 17:20:10 +0100 Here's a patch for src/Makefile as find obj on local & ports failed in the case that src/local or src/ports was a sym link ---------------------------- revision 1.32 date: 1994/01/11 08:06:49; author: rgrimes; state: Exp; lines: +11 -1 Added the following so that people can have these built automatically if they like: # This is for people who want to have src/ports, src/local built # automatically. .if defined(MAKE_LOCAL) & exists(local) & exists(local/Makefile) SUBDIR+= local .endif .if defined(MAKE_PORTS) & exists(ports) & exists(ports/Makefile) SUBDIR+= ports .endif ---------------------------- > * Now, the new ports stuff has changed the picture a little and we > * need to deal with it, not just go nuke it! > > Well, one thing is that the older ports paradigm is different from > the new one. It's not only the location, it uses a pretty much > different way to build the thing, we don't have the source under there > anymore, etc. This should not effect the desire to have make world do the whole tree, the src tree build paradigm may very well change some day, so what, it does not effect this issue, nor should it. Building is building. > * The argument that that /usr/src should know nothing about /usr/ports > * is a strawman, as bsd.port.mk lives there along with several other > * bits. Ideally, sure it would be nice if it didn't know a thing about > * it. Practical view point, next to imposible to achive the ideal. > > Now that's an argument for the sake of an argument. Sure the *source* > of bsd.port.mk is in /usr/src, but it is installed in /usr/share and > that's what we are using. No, that is not ``an argument for the sake of an argument''. It is a statement of reality. Your point that it is in /usr/share means that the ports mechanism has contaiminted a standard part of the system, only makeing the case stronger that the ideal can not be achived. > I'm not saying /usr/src shouldn't know anything about /usr/ports, I'm > saying /usr/src/Makefile should't. /usr/src/Makefile's job is to > build the operating system, and it just happens that one of the > utilities (BSD make, well actually some if its macros that we added) > knows something about the ports. /usr/src/Makefile's job is what we make it do, it is sad that you where not here 1.5 years ago when this decission was made. And I still agree with the original arguments and concerns that where expressed back then. I do not like the fact we have to repeat history every 2 years and make decissions over and over. This has become a waste of time, and I no longer really care what happens to those 6 lines, but you will be reversing a decission that has a 2 year standing precedent by doing so. > * And as Joerg pointed out /usr/src/ports -> whereever makes the > * current code just do the right thing, and that was more or less > * the original intent. If someone wanted there ports collection > * autobuilt during a make world they just added the symlink and > * set MAKE_PORTS and boom, bigger longer running more complete > * ``make world''. > > Maybe I should say that ports is not a subdirectory or a subsidiary of > any sort of /usr/src. That's why I keep saying "this doesn't belong > here". And if you want to do it "boom", you can just type "make world > && cd /usr/ports && make". :) Why didn't we go this route in the > first place? Because ``make world'' is shorter, and the actual sequence of events will be slightly different for you 2 sets of commands. If you really want to know, go dig it out of the mail archive. Ports is a subsidiary of /usr/src, just as / is, the whole bloddy FreeBSD world is a subsidiary of /usr/src. Why are you arguing so hard over 4 lines of code that are in effect a nop for most sites, and give others some added funcitonality. > * You'll also notice all sorts of things in src/Makefile to handle > * the fact that src/ports may very well be a symbolic link, so this > * is not an ``after the fact'' side effect, it was designed that > * way. > > Well, the stuff about the obj links and stuff are useless. We don't > have them in the ports tree (and I don't think we ever had). Then again, this is ports changing without propery keeping src in sync with the changes in the paradigm. > * [gee, 60 lines of comments to defend 10 lines of code :-(] > > I don't understand why it's so hard to get my point across, this thing > just doesn't belong in /usr/src/Makefile and never should have been > put in. We don't have a link /usr/src -> wherever/ports, we don't > even have /usr/ports installed as part of the base system (I want this > to be fixed though). Because this point was argued 2 years ago, and you seem to be the only one mounting a case to change it (and I the only one in it's defense because I was there when it was done and know it took a lot of convincing to get it added, but it was a _group_ decission to do it.) Your just too late!!! > This problem should have been solved by the user typing both commands > from the command line, not by adding cruft to our /usr/src/Makefile, > and I don't think it's too late to clean it up. Give a user a feature and take it away later and they will be mad at you about it, plain and simple. I don't like mad users. > I understand that this thing was designed carefully, it will work > beautifully (minus the ports tree not actually building very well :<) > if you have the right symlinks and stuff, and I apologize for hurting > the feelings of the people who worked hard to add it here and make it > work right. > > But lately our Makefiles and *.mk files are getting way too > complicated, we need to try to reduce their complexity, that's why I > barked at Jordan when he added a new variable instead of deleting a > few lines. If you want to go work on something getting ``way too complicated'' work on what you have been. bsd.port.mk by and far is the most complicated make related thing we have in the tree!! /usr/src/Makefile is trivial compared to it. Wanting to remove complexity is a good goal, but never at the cost of functionality. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507210223.TAA10403>