From owner-freebsd-hackers Sat Jun 21 13:12:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA17048 for hackers-outgoing; Sat, 21 Jun 1997 13:12:43 -0700 (PDT) Received: from radford.i-plus.net (root@Radford.i-Plus.net [206.99.237.6]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA17041 for ; Sat, 21 Jun 1997 13:12:40 -0700 (PDT) Received: from abyss.i-Plus.net (pitlord@Abyss.i-Plus.net [206.99.237.44]) by radford.i-plus.net (8.8.5/8.8.5) with SMTP id QAA00968; Sat, 21 Jun 1997 16:10:58 -0400 (EDT) Message-Id: <199706212010.QAA00968@radford.i-plus.net> X-Mailer: Microsoft Outlook Express 4.71.0544.0 From: "Troy Settle" To: "Mike Tancsa" , "Jordan K. Hubbard" Cc: Subject: Re: make world error in RELENG_2_2 Date: Sat, 21 Jun 1997 16:10:31 -0400 X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From: Jordan K. Hubbard >I think the real problem here is that some folks are simply unclear on >the amount of "expertise" required to use /usr/src as an effective >upgrade tool. I would hardly call myself an expert. I tried to make world several dozen times a few weeks ago, and finally reached the point of giving up. I had posted -questions, and asked on IRC. In fact, I talked to you a bit about it, but still no go. >You ask why we don't document the world target - but we do! >/usr/src/Makefile is the documentation for the world target, and >before you start laughing and figuring 'ol Jordan is copping-out here, >let me just explain that for anything which requires building from >sources, we *definitely assume* a very comfortable degree of knowledge >in how to analyze Makefiles and see exactly what they are doing, up to >and including making inferences about where the dependencies are and, >if necessary, taking whatever steps are necessary to ensure that a >failed build is jump-started from the right place. Yes, the handbook even says to check out /usr/src/Makefile before attempting to make world. However, for beginners, it's not quite enough. After reading other posts in this thread, I have gained enough clues to finally succeed in making the world. The only problem I had, was getting /usr/include up to speed. The only way I was able to do this, was by removing it before starting. This had it's problems too. There were a few instances where I had to backtrack, and make a few directories by hand. I don't remember all of them right off, but they included: /usr/include/arpa /usr/include/g++ (and a few under that) /usr/include/readline /usr/include/rpc /usr/include/rpcsvc /usr/include/ss It wasn't anything major to deal with... just a pain 'cause I had to keep starting over. >The world target *does* generally work, don't get me wrong, but it's >also exceedingly easy to get to a point where the delta between where >you are and where /usr/src would like to take you has diverged too far >to allow "world" to actually work. In such cases, you need to know >how to shepard the process through by hand and the Makefile truly says >it all where that's concerned. I can't imagine any more effective or >concise body of documentation than the build system itself to someone >who knows what they're doing, and someone who doesn't know what >they're doing really shouldn't be using the world target - they should >be hanging back at the major release points and upgrading via binaries >only. What about those of us who want to learn about this stuff. It's not difficult once one gets a few clues. But, those clues are a little less than obvious to many of us. >We're proud of our integrated build system and, given that it's also >often the quickest way of getting a fix into a user's tree, we do >sometimes tend to recommend it as a solution in situations where we >really shouldn't. Building from source is NOT a generic, >targeted-at-the-end-user kinda mechanism and I'm sorry if we ever lent >that impression. It's not. It's for software engineering types to >use, those who are more than comfortable with the idea of reading >Makefiles and figuring it out, and in that sense I'd say it's probably >as documented as it's ever going to be. FreeBSD's integrated build system is something to be proud of. I'm sure it took years of work to develop it, and I'm sure it will continue to grow. The problem is the learning curve. Whereas those persons that have been with FreeBSD since the beginning, this is all child's play, there are even more of us that have only been with FreeBSD for a short time, and need a little help now and then. Someday, when time permits, and my coding experience has grown, I hope to become an active contributer to the FreeBSD project, but there are many things that must be learned first, and it's not an easy road when honest questions are given sarcastic or very short replies. Calling us stupid or lazy doens't help anything. Sure, I'll bet that there's people out there that would rather have everything handed to them on a silver platter. Me? I want to learn, and sometime, I'm going to need some help. A qualified answer to an honest question is the best way to help someone in my position. Sarcasm won't stop me from asking, it just pisses people off. >This is also hardly the "elitist" stance some might see it as - it's >just being honest about how this process works and hardly unknown in >this industry. If you walked into IBM tomorrow as an engineer, for >example, and were tasked with porting some large, obscure product of >theirs from AIX to another UNIX variant, do you think you'd find a >source tree with a carefully documented build system, all easily >understandable in a ten minute study? Ha Ha. No. What you'd find >instead is almost certainly something which was completely opaque to >the average joe and aimed strictly at those who know how to take a >build system apart in its entirety, say "aha, so THAT is what you >idiots had in mind", and then adapt it to the new target system (or, >as I've frequently done in such situations, do it over since the >original designers had all the pan-UNIX expertise of a team of Visual >Basic programmers and did it wrong for anything _but_ AIX). In some ways, I do see an "elitist" stance, but it's not one of total seperation. The tools and information is there for everyone to see and study. With time, anyone could learn the details of the FreeBSD build system. The problem, is getting over the first hurdle of the learning curve. Today, I finally got RELENG_2_2 to build, and a few minutes later, I used my newly found knowledge to help someone else get 3.0 to build. >That's just the nature of the beast, and if anything I'd say that >FreeBSD has one of the _easiest_ build systems to understand. >You really have it easy, so quit whinging and start reading the >Makefiles in the future, OK? :-) Yes, now that I've got a few clues, it is pretty easy stuff. Like I said above, the first hurdle of the learning curve is the hardest. Well, I've gone on enough about this. I gotta get back to upgrading and cleaning my box. It's turning into a fun ride :) -- Troy Settle Network Administrator, iPlus Internet Services http://www.i-Plus.net