Date: Thu, 31 Jul 1997 20:18:54 +1000 From: Bruce Evans <bde@zeta.org.au> To: current@FreeBSD.ORG, reg@shale.csir.co.za Subject: Re: More bogons in Makefiles... Message-ID: <199707311018.UAA26613@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707311018.UAA26613>