From owner-freebsd-arch@freebsd.org Thu Mar 9 22:58:21 2017 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 2B9E9D0525E for ; Thu, 9 Mar 2017 22:58:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 E4512217 for ; Thu, 9 Mar 2017 22:58:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id g138so76503256itb.0 for ; Thu, 09 Mar 2017 14:58:20 -0800 (PST) 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:from:date:message-id :subject:to; bh=yIhXZBpI2+vyfw1iROh4dP9AxP0c/xdTHVGg2PT0Bho=; b=Vb8CAFWUpEI4e7Ug0R3g9Qb6opujQ5nktvBi5JWCKVqOm0W6qXIvdZBNcKh22T/jtF Qdo3sze3vgSyfh+EMJ/oYTeCIQ1cUT2WbW3tqg2hhBWmn2tWJqOa/+FF/kQsbztNq08f kc+s93Oszpk1DJClfLFodHQPjO8BJicIEVsSUV1ffcDwRTPebF05rMdtbKo20/ZUdpIz +SyDu+Ynmw1Tw0H251RQ6z3jOHXF40VLRQalb+e1EgzUacMPKNwEgpoZyE4ZOqT5xtNq qd9oOmA/uXjyaVcBA1VBxHKJ+8qi18oWkATlObvK1es40Dqio6KhQcevhsGsYFWNBdYX CcrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=yIhXZBpI2+vyfw1iROh4dP9AxP0c/xdTHVGg2PT0Bho=; b=kpytdaZzrWBg+bdrwyWtiS4Rywa6gdzj5GmcupEiayoQ42AnuQGAPBXK5kZVHPI0qi GicxPhuJacMrVC+TKGjlf91MchwFwLLBVdnLSdoC1DIrFWQvlEngXA8w3jx9pba4GX8h RJuBGzGryb+niA8yF5ZxKUrAd4ufl/WCzOAhAlHU6HHAsFUKa3ZlxTHsI08XSYgHLUsD vj8HEpMKAxdVoWs6YJF3vv0xUtR9KutOhwbxCrhI4d4yqZgsiSg8ZAQjzl9+F0m1bLtw yQ0wVQccQ6ZgQDsabaYPdb14Vkx5MnLU9MpuF+ksaIjFAAQawU8r9dLzIfLuIKaOeVM6 WDTw== X-Gm-Message-State: AMke39mptvQS/Ixorqr8eFMpAVtvB0+lIvlxYitXLeUwf5HL3TgxIucn7WBHOEsU7mdtfmyu+Z2Ef9YG9UKE8w== X-Received: by 10.36.116.71 with SMTP id o68mr15186466itc.60.1489100299701; Thu, 09 Mar 2017 14:58:19 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.129 with HTTP; Thu, 9 Mar 2017 14:58:19 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: References: <201703042039.v24KdcDE078734@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Thu, 9 Mar 2017 15:58:19 -0700 X-Google-Sender-Auth: _eOv967NXJrP-x5jBvc6Tbb7Aks Message-ID: Subject: Re: svn commit: r314654 - in head/cddl: lib/drti lib/libavl lib/libctf lib/libdtrace lib/libnvpair lib/libumem lib/libuutil lib/libzfs lib/libzfs_core lib/libzpool sbin/zfs sbin/zpool usr.bin/ctfconver... To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 22:58:21 -0000 [[ redirected to arch@ ]] On 3/4/17 3:39 PM, Rodney W. Grimes wrote: > Idk, maybe I am to personally attached to the relative paths.. cause I > had a major part in helping them all to work, or perhaps its my been > burned by absolute paths that had to be reworked too many times in > my past. But my gutt is telling me this change is Bad(tm). OK. Reading through this entire thread, it looks like the general consensus is to move to SRCTOP. Let me summarize the reasons. To summarize: We have never used relative paths. The paths have always been absolute. SRCTOP makes the paths shorter in the Makefile as well as making it possible to move Makefiles around. These two very real benefit have not been offset against any tangible reasons to not do this. ${.CURDIR} has always been an absolute path, and the makefiles have always used ${.CURDIR}/.../../blah to reach over to some place else in the tree. But these "tree relative" absolute paths are the worst of both worlds. They fossilize the locations of the Makefiles because they can't only be moved to a limited number of places. They bloat the paths needlessly which increases the output of the commands (and also makes the deepest top directory you can build from significantly shorter). There never was a good reason to use the ${.CURDIR}/.. construct other than SRCTOP simply never existed until recently. So unless people can articulate a coherent reason to not do this, I plan on moving ahead on SRCTOP. This was the consensus of the folks maintaining the build system before this commit and remains the general (though not unanimous) consensus after the discussion. The first of the code reviews is here, which try to duplicate the work ngie@ did on the topic, but with only the SRCTOP changes for the moment: https://reviews.freebsd.org/D9932 There was a prior arch@ thread: https://lists.freebsd.org/pipermail/freebsd-arch/2017-March/018117.html which generated no objections as well, adding to my opinion that we have consensus. I'll do others for the rest of the tree and commit them in 'chunks' the size of top-level components (or maybe smaller if those chunks are too large, since it's better for external people to have 10 smaller chunks to merge than 1 larger chunk). I hope to push this in sometime next week. Warner