Date: Mon, 24 Jul 1995 02:11:39 -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: <199507240911.CAA18082@gndrsh.aac.dev.com> In-Reply-To: <199507240757.AAA20449@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Jul 24, 95 00:57:14 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Rod, it doesn't seem like we are going to reach any sort of agreement, > but here it goes another one.... Go nuke it, but you have to respond to any site that complains about lost functionality if there was some one using it. I don't really care about the lines, I just know it took 2 weeks to convince me to add them, so I am not so happy to see this suddenly reversed with out as much convincing. Maybe I should have been more stuborn about adding them in the first place :-). > * If you think /usr/src/Makefile is complicated, go read release/Makefile > * for some enjoyment... > > The release tree is not for general consumption. ;) /usr/src is for general consumption, everything, including src/release. You might not be interested in it, but others are. > * 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 :-) > > I know, and believe me, I'm going to clean this thing up. It's long > because there is lots of code duplication, because I didn't know how > to use macros. :p :-). I suggest you read the pmake tutorial in the 4.4BSD man set, also as /usr/share/doc/psd/12.make/* on your FreeBSD 2.x system. It doesn't cover .mk files per se, but it does cover a lot of ground. > * Yes, it did, here is some of the rcs log that effected the change: > > Thanks. Is there somewhere I can check the old commit logs? You need a 1.x cvs tree, we can't have a 1.x cvs tree on Freefall legally, and I am not suppose to have one here myself :-(. > * 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. > > But that doesn't mean we should try to keep them separated as much as > possible. That may not mean it, but I am pretty sure the standing idea here is that ports should not contaminate /usr/src with port specific changes. > * 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 > > Where can I find the old mail archives? /home/mail/archive on freefall. > * > 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. > > This only proves my point, nobody in the ports group didn't even think > about /usr/src/Makefile (I didn't even know ports is mentioned here!) > when this change occurred. :-(. > I'm just trying to keep the inter-depencies of the two trees to a > minimum. > > * 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!!! > > Well, we got replies from two others, Jordan's "I prefer it nuked" and > Julian's "nuke it if you want". And we can still delete it with a > group decision. Julians reply was before I patched it, which was before I remeber the idea was that it would be a symlink to the location of ports. If Julian and Jordan say nuke it still, then go nuke it, but like I said in the opening. Any site complaining about lost functionality lands right in your lap. There are tons of things in unix that could be done with a few commands strung togeather, but are not. (nm -n => nm | sort), etc, etc. -- 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?199507240911.CAA18082>