From owner-freebsd-arch@freebsd.org Sun May 29 04:58:40 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66633B4F9DA for ; Sun, 29 May 2016 04:58:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28048105F for ; Sun, 29 May 2016 04:58:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x241.google.com with SMTP id z123so3118511itg.2 for ; Sat, 28 May 2016 21:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=jnVNcJAHN8GZiP419r+fa3ctZomBbpVCNhVS/ClVkVo=; b=b5tJ9gsgACraVfuHS5zi0gQeH+vtAhaW00GkfSsUKBdUEn5+0PfyH52fhcwvXLanHj Fi3NVQzQCfUilxN6LPA1wupkhT9d+h/b2xUsgfKt9PeNpQkTKud6e9Pp5XbcTQBTpkn2 EXu+7OKNjCtc5fzZfH1HA2g9oTiFqNuhX8plx1XLCUIcK3BtblY1Jegirw1MLNxUWvEa B8YVn2FF0rpgrUtixOQzBjYpRFMBHJZy+gA8kTfO87FVBkPYDnm2qX4ASw0csFnQMbfj fyAeBI4JKRpkMcORS43bGE79F39rIzCYyn1LAc5a9PSHuCbOw14S4Zf/WOs7yQher/KF Lb/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jnVNcJAHN8GZiP419r+fa3ctZomBbpVCNhVS/ClVkVo=; b=E50TF+dCcwAOVb80tv6Ar9JLQI96dlvlCTP4U/YXHK5gpGDq9Hjjo4rSy9C6s8iKr+ fOCgRQ8bWso4TZY/frbYf2eZpLhnGB7sfNsXBJiDU8ZXdXokhpj9enRBtGXdcHpsej/r IAasoCXGbdNQ+5KX2sxuRISBsLtwlMcGWp0TE1jqWxGBP1On6Ag31mkJbvsrBiKAnBLF qUTc8IIr6dDR7G3t4lJc4zEKMpWUBLPb32kHS5tsY65Ad2YUnLw/FKHtD28GOzzHxauE eNxWkcTfbApub8CmbAekNu7rybwmDrniQbSvb94CjyRREQAZe06JbAptp9vprNcIObOr GazQ== X-Gm-Message-State: ALyK8tKwkBermzIPE6kC2YRlU7iy+KN+kZKWneXDktX9reizuLTyFXHYGrFLtUYa08GAlmrTCNK9P7LixNg5oQ== MIME-Version: 1.0 X-Received: by 10.36.78.67 with SMTP id r64mr3904622ita.72.1464497919482; Sat, 28 May 2016 21:58:39 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.75.68 with HTTP; Sat, 28 May 2016 21:58:39 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <5e8f0d99-dab1-36a8-1aac-328de4490145@FreeBSD.org> References: <5e8f0d99-dab1-36a8-1aac-328de4490145@FreeBSD.org> Date: Sat, 28 May 2016 22:58:39 -0600 X-Google-Sender-Auth: LMno8R13gFvWvURJeBd7JYHNMgQ Message-ID: Subject: Re: [Build] Enabling automatic object directory creation From: Warner Losh To: Bryan Drewery Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 04:58:40 -0000 On Wed, May 25, 2016 at 12:20 PM, Bryan Drewery wrote: > For in-tree source builds only, I would like to make it so that 'make' > in a subdirectory would automatically create the object directory. This > would naturally extend to buildworld/buildkernel as well with some > tweaks. I already am nearly done with adding this in for buildworld and > was going to just make it happen since the 'make obj' tree-walk is a > waste of time. It is very error-prone to not automatically create an > object directory when building in a subdirectory as it may look for > files in the wrong place. So I would prefer to add it everywhere instead. > > What is the impact of this feature? > > Keep in mind this would *only affect in-tree builds, not ports*. > > We would need to move the 'default' MAKEOBJDIRPREFIX from > Makefile/Makefile.inc1 into share/mk/sys.mk. It would only be > overridable from environment and make argument, but also > /etc/src-env.conf (I think). This restriction is already in place. I > would have to move the assertion for this out of /Makefile and into > sys.mk. Now when I say sys.mk I really mean something like > src.sys.env.mk. which is hidden in a way to only impact in-tree builds. > > The feature is named 'WITH_AUTO_OBJ'. Enabling this by default means > that the only way to disable it is to add WITHOUT_AUTO_OBJ=yes to > environment, make argument or /etc/src-env.conf. I tend to think this is a good idea. However, more and more is moving into sys.mk, and it's been collecting lots of odd pebbles... > There are times when building in a directory without an object directoy > makes sense, but for the vast majority of people they likely have done a > buildworld already and are trying to build in a subdirectory to test > something further. If they pulled down new revisions then it is > possible that this new directory did not get a 'make obj' tree-walk. > > A side topic is changing the default MAKEOBJDIR such that it always uses > ${MAKEOBJDIRPREFIX}/${SRCTOP}/${TARGET}.${TARGET_ARCH}/${RELDIR}. Doing > this is far simpler if I can just use WITH_AUTO_OBJ everywhere. This is > discussed a bit in https://reviews.freebsd.org/D3711. It would give > directories such as: /usr/obj/usr/src/amd64.amd64/bin/sh. It would keep > all universe/cross-builds inside of /usr/obj/usr/src and allow more > easily cleaning up object trees with multiple checkouts. This object > tree pattern is what the DIRDEPS_BUILD uses as well and has been quite > handy. I would extend the DIRDEPS_BUILD 'make destroy' and 'make > destroy-arch', to the normal build, to cleanup the entire object tree > for the object directory and the specified target.target_arch respectively. I think this is a good idea. I've had hacks like this in the past because they are quite useful. though named differently and perhaps with different scopes. Warner