From owner-freebsd-current Thu Jul 31 03:22:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA25888 for current-outgoing; Thu, 31 Jul 1997 03:22:35 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA25878 for ; Thu, 31 Jul 1997 03:22:29 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id UAA26613; Thu, 31 Jul 1997 20:18:54 +1000 Date: Thu, 31 Jul 1997 20:18:54 +1000 From: Bruce Evans Message-Id: <199707311018.UAA26613@godzilla.zeta.org.au> To: current@FreeBSD.ORG, reg@shale.csir.co.za Subject: Re: More bogons in Makefiles... 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 > this, which might cause problems if the module is built without a full > src tree. Paths relative to the source tree are preferred, although this causes problems with partial source trees. Paths relative to the object tree are used by many sloppy Makefiles (this works if the object tree has the same layout as the source tree, and fails messily if you do things like "cd /usr/src/gnu/usr.bin/cc/cc; mkdir obj; make COPTS='-g -static' to attempt to build a temporary debugging version of cc. This should work if the rest of cc has already been made, and used to work when the object tree was inside the source tree (perhaps actually elsewhere with a per-source directory obj symlink)). Non sloppy makefiles would use a more complicated search for the object directory that would actually be used if `make' were run in the external source directory. > I percieve the purpose of 'make world' to be to make sure that > these libraries get installed before the build happens. Or are these `make world' attempts to do this, among other things, but only for standard libraries. It fails in many cases when DESTDIR is set (the libraries get installed under ${DESTDIR} so the old libraries in /usr/lib get linked to). >2. There are a lot (15 or so, like cc, cvs) programs which have library > directories, which are not installed, but are depended apon. If you cd to > one of the subdirectories (without /usr/obj populated) and do a 'make > all' then it falls over in the linking stage... I know: "Don't do that". > 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? There doesn't seem to be a clean way. tn3270 attempts to build things outside the current directory, but makes a mess of it. >3. There are a lot of tests of the form: > > .if exists(../../secure) && !defined(NOCRYPT) && !defined(NOSECURE) The path here should be ${.CURDIR/../../secure}. `make' chdir's to the object directory early, so most paths are relative to the object directory (relative `.include' paths are searched for first in the source directory, then in the current (object) directory). > It seems that NOCRYPT could be set if NOSECURE is set, and NOSECURE set > if there was no directory (../../secure), tested from a Makefile or > Makefile.inc in /usr/src or elsewhere, saving a bit on tests and possible > mix ups. The idea is for optional sources to automagically be used completely if they exist. >--- ./share/doc/usd/Makefile Wed Jul 30 01:03:20 1997 >... >! .if exists(../../../games) && !defined(NOGAMES) >! SUBDIR+= 30.rouge 31.trek >! .endif The path should be relative to ${.CURDIR} >*** ./share/zoneinfo/Makefile.orig Thu May 22 11:34:30 1997 >--- ./share/zoneinfo/Makefile Wed Jul 30 01:03:24 1997 >*************** >*** 16,22 **** > TZFILES+= backward > .endif > >! .if exists(${.OBJDIR}/yearistype) > YEARISTYPE= ${.OBJDIR}/yearistype > .else > YEARISTYPE= ${.CURDIR}/yearistype >--- 16,22 ---- > TZFILES+= backward > .endif > >! .if exists(${.OBJDIR}) > YEARISTYPE= ${.OBJDIR}/yearistype > .else > YEARISTYPE= ${.CURDIR}/yearistype > >Something tells me this hasn't been used for a while ;): The old version worked, except when yearistype hasn't already been created and make is invoked as with args `all install' to create and install in the same invocation. There are more bogons here. The whole ifdef is a verbose and confusing way write `YEARISTYPE= ${.OBJDIR}/yearistype. yearistype is always created in the object directory and ${.OBJDIR} always exists (although it's not clear where it is when make is invoked with args `obj all ...'). >--- ./bin/Makefile.inc Wed Jul 30 01:51:06 1997 >... >--- ./bin/ed/Makefile Wed Jul 30 01:11:58 1997 > [LIBCYPHER changes] >Why doesn't libcipher have an entry in bsd.libnames.mk? and shouldn't there Because I don't use it :-). bsd.libnames.mk is no longer used in -current, so this problem will go away automatically. >be some ${DESTDIR}'s near those ${BINDIR}'s (Also in ./bin/test/Makefile)? >That's what ./share/mk/bsd.README says... There's lots of those around the >tree. Not sure. See similar fixes for moving defines for init from sbin/Makefile.inc to sbin/init/Makefile. >Oops, one last thing: should ./usr.bin/lex/lib be built twice in the >bootstrapping of 'make world' (as part of lib-tools and libraries) and It doesn't hurt. >should the whole of ./lib be rebuilt, including stuff that's been done a >minute earlier? only libc and libm are needed, as far as I can see, to make >the build-tools targets before the libraries are built anyway as part of the >'make all'. The idea is that the library tools, especially the compiler, might have changed, so everything needs to rebuilt. Too many things are probably built before various toolsets are built, but this isn't easy to fix without modifying some of the tools to have fewer prerequisites. Satoshi has a version of src/Makefile that is more careful about building and using all prerequisites. It builds even more unnecessary things. Bruce