Date: Fri, 15 Oct 1999 13:57:24 +0200 From: Marcel Moolenaar <marcel@scc.nl> To: arch@freebsd.org Subject: make world issues Message-ID: <380716A4.20961526@scc.nl>
next in thread | raw e-mail | index | archive | help
Some flaws in the "make world" became apparent when the sigset_t
datatype changed. One of the biggest problems right now is that we don't
have an upgrade path from -stable to -current. Especially with 4.0 being
released early next year. I want to start a discussion here on how to
properly implement make world. I start of with known issues/problems and
some points that are not necessarily problems. Following that I give an
indication of what I'm thinking about by summing a number of design
"points" that I have in mind. I finish with the notion that you can help
:-)
Known issues/problems:
P1. the upgrade path is broken.
P2. aout to elf seems to be broken too.
P3. no cross compilation.
P4. buildworld must be performed as root.
P5. sys.mk pollution.
Questionable issues:
P6. no kernel is made as part of world.
P7. installworld may fail for -j>0.
P8. makefile complexity.
P9. dumb make process.
ad P7:
it is possible for a task to want to run install while another task is
installing it.
ad P9:
a buildworld starts by clearing /usr/obj by default and then generating
everything. This can be controlled by NOCLEAN and NOTOOLS, by which you
enter the twilight zone :-)
Make world design points:
D1.
redesign the make world process from scratch. This should prevent P8
from becoming worse and also may help solve P5.
D2.
introduce TARGET_ARCH and TARGET_OBJ to specify for which architecture
and object format we are building (resp.). MACHINE_ARCH and MACHINE_OBJ
will be set to reflect the current (ie running) environment. This should
help fix P3.
D3.
assume 3 "roots" in the build-process: SRCROOT, OBJROOT and INSTROOT.
These point to the root of the source tree, the root of the object tree
and the root of the install tree (resp). SRCROOT is assumed to be
read-only. OBJROOT is assumed to be writable by priviledged users and
INSTROOT is assumed to be writable by root only. This should help fix
P4.
D4.
allow concurrent cross-builds by defining a TRGTROOT under OBJROOT using
TARGET_ARCH and TARGET_OBJ. If, for example, OBJROOT=/usr/obj,
TARGET_ARCH=i386 and TARGET_OBJ=elf, then TGTROOT can be defined as
cross-build for the Alpha can be performed at the same time
(TRGTROOT=/usr/obj/alpha/elf). This may help in fixing P9 and may be
advanteous in making snapshots and releases on build-machines.
D5.
build tools that are necessary for cross-building only if necessary. If
possible use the installed tools. If tools need to be made, make them as
machine native binaries and install them under TRGTROOT. This implies
that includes are taken from /usr/include and that libraries are
sought from /usr/lib. This helps P3 and P9.
D6.
do not use chown, chgrp and chflags for anything created and installed
under TRGTROOT. This fixes P4.
D7.
make a kernel as part of the build process. Use GENERIC if KERNEL has
not been befined, otherwise make ${KERNEL}. This helps P1 and P2 and
solves P6.
More vague points:
D8.
the build-process starts with creating a minimal hierarchy under
TRGTROOT, after which all necessary tools are checked and created if
necessary. The build should start with includes and libraries, followed
by everything else according to dependencies.
D9.
allow a "smart" build by taking modifications to makefiles into account.
If for example /usr/src/usr.bin/Makefile has been updated after
/usr/obj/.../usr.bin has been created, remove /usr/obj/.../usr.bin
completely. This also holds for programs/libraries. This should minimize
unnecessary rebuilding, but with the proper conservatism. A second
builworld should therefore don't have to do anything when it is started
immediately after the first has completed.
D10.
it should be possible to build a single program just as it can be done
now.
There are probably more points, but this is what comes to mind first. If
you have suggestions, criticism, additions or time, let me (us) know!
thanks,
--
Marcel Moolenaar mailto:marcel@scc.nl
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD project mailto:marcel@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?380716A4.20961526>