From owner-freebsd-arch Fri Oct 15 5:24: 6 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 14BE314CDE for ; Fri, 15 Oct 1999 05:24:00 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA00316 for ; Fri, 15 Oct 1999 14:23:58 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA48726 for freebsd-arch@freebsd.org; Fri, 15 Oct 1999 14:23:57 +0200 (MET DST) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 8558B14CDE for ; Fri, 15 Oct 1999 05:23:46 -0700 (PDT) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id NAA00353 for arch@FreeBSD.org; Fri, 15 Oct 1999 13:57:32 +0200 (CEST) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Fri, 15 Oct 1999 13:57:24 +0200 From: Marcel Moolenaar Message-ID: <380716A4.20961526@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: make world issues Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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