From owner-freebsd-current Wed Jul 30 23:38:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA09207 for current-outgoing; Wed, 30 Jul 1997 23:38:13 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA09200 for ; Wed, 30 Jul 1997 23:38:11 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.6/8.6.9) with ESMTP id XAA19898; Wed, 30 Jul 1997 23:37:16 -0700 (PDT) To: Jeremy Lea cc: current@FreeBSD.ORG Subject: Re: More bogons in Makefiles... In-reply-to: Your message of "Wed, 30 Jul 1997 22:52:35 +0200." <19970730225235.58179@shale.csir.co.za> Date: Wed, 30 Jul 1997 23:37:15 -0700 Message-ID: <19894.870331035@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 1. What is the "general" policy with Makefile's pointing to directories like > ${.OBJDIR}../../foo/bar when the library (normally) in question is > installed in /usr/lib? In a number of places there are references like Ah, but maybe it's not yet, eh? Or maybe it's entirely the wrong version because you're building a source tree for a different release of FreeBSD than the build host is running. Assuming anything about the contents of the final destination directories for what may be a simple build is highly bogus and, while this is still done in a number of places in /usr/src, the eventual intent is to get rid of this and make /usr/src build in a properly self-referential fashion. > src tree. I percieve the purpose of 'make world' to be to make sure that > these libraries get installed before the build happens. Or are these It's the current kludge of `make world' to do this, but it's still not its most ideal purpose. :) > Is there a clean way of building and installing the lib in > ${.OBJDIR}/.. as a first step in the Makefile, and cleaning it from the > other subdirectory's Makefile if only that subdirectory was built? Not really, no. Not a clean way. :-) > [ numerous bogons identified and diff'd ] Yes, as you can see, things aren't always 100% consistent in there and you've certainly identified some definite bogons. I or someone will review and commit from this list fairly shortly. > Anyway, that's all for now. I'm still trying to understand make, *.mk and > the Makefiles. You seem to be doing pretty well so far. :-) Jordan