From owner-freebsd-arch@freebsd.org Tue Dec 8 08:56:00 2015 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 C633C9D2F11 for ; Tue, 8 Dec 2015 08:56:00 +0000 (UTC) (envelope-from pho@holm.cc) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B2F98164C for ; Tue, 8 Dec 2015 08:56:00 +0000 (UTC) (envelope-from pho@holm.cc) Received: by mailman.ysv.freebsd.org (Postfix) id AF91B9D2F10; Tue, 8 Dec 2015 08:56:00 +0000 (UTC) Delivered-To: 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 96A3F9D2F0E for ; Tue, 8 Dec 2015 08:56:00 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53E42164B; Tue, 8 Dec 2015 08:55:59 +0000 (UTC) (envelope-from pho@holm.cc) Received: from x2.osted.lan (87-58-223-204-dynamic.dk.customer.tdc.net [87.58.223.204]) by relay01.pair.com (Postfix) with ESMTP id 0ED93D006C2; Tue, 8 Dec 2015 03:55:57 -0500 (EST) Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.9/8.14.9) with ESMTP id tB88ttGu000893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Dec 2015 09:55:55 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.9/8.14.9/Submit) id tB88ttkr000892; Tue, 8 Dec 2015 09:55:55 +0100 (CET) (envelope-from pho) Date: Tue, 8 Dec 2015 09:55:54 +0100 From: Peter Holm To: Gleb Smirnoff Cc: jeff@FreeBSD.org, alc@FreeBSD.org, kib@FreeBSD.org, scottl@FreeBSD.org, arch@FreeBSD.org Subject: Re: new vm_pager_get_pages() KPI, round 3 Message-ID: <20151208085554.GA60158@x2.osted.lan> References: <20151205052940.GJ42565@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151205052940.GJ42565@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 08:56:00 -0000 On Sat, Dec 05, 2015 at 08:29:40AM +0300, Gleb Smirnoff wrote: > Hi, > > [first paragraph for arch subscribers, To: recepients may skip] > > This patch is kinda a prerequisite for the non-blocking sendfile(2), > that was jointly developed by NGINX and Netflix in 2014 and has been > running in Netflix production for a year, serving 35% of the whole > North America (US, Canada, Mexico) Internet traffic. > Technically, the new sendfile(2) doesn't require the new > vm_pager_get_pages() KPI. We currently run it on the old KPI. However, > kib@ suggested that we are abusing the KPI, carefully using its > edge cases. To address this critic, back in spring, I suggested a KPI, > where vm_pager_get_pages() offers all-or-none approach to the array of > pages. Again, kib@ wasn't satisfied, as for "the main user" of > vm_pager_get_pages, the vm_fault(), all-or-none approach isn't optimal. > The problem was slowly debated through the summer. And then in October > jeff@ suggested yet another extension of the KPI, which I have > implemented and it is described below. > > [for those interested in new sendfile(2), skip to the last paragraph, > for those willing to review new pager KPI, read on] > > The new KPI offers this prototype for vm_pager_get_pages(): > > int > vm_pager_get_pages(vm_object_t object, vm_page_t pages[], int count, > int *rbehind, in *rahead); > > Where "count" stands for number of pages in the array. The rbehind > and rahead if not NULL specify how many pages the caller is willing to > allow the pager to pre-cache, if the pager can. > > Pager doesn't promise to do any read behind or read ahead. If it does, > then only the pager is responsive for grabbing, busying, unbusying and > queueing these pages. It also writes the actual values of completed > read ahead and read behind back to the pointers. > > Pager promises to page in "count" pages or fail. Pager expects the > pages to be busied, and returns them busied. For a multi page requests, > the pager demands that the region is a valid region, that exists in > the pager, which can be checked by preceding call to vm_pager_haspage(). > For single page requests, there is no such demand. > > The net result is a win for both vm_fault() and for new sendfile(). > > The vm_fault() no longer needs to do prepatory vm_pager_haspage(), > which removes one I/O operation. The logic for read ahead/behind, > which is strongly UFS/EXT-centric, moves into vnode_pager.c. So > we no longer do useless operations when having a fault on ZFS. > > The vm_fault() now knows precisely the read ahead that happened, > when updates fs.entry->next_read index. This reduces number of > hardfaults by a tiny fraction (measured building world tree). > > The new sendfile() has a stronger KPI, that doesn't unbusy pages, > that sendfile() needs to be kept busied. > > Also, the new KPI removes some ugly edges. E.g., since the old > KPI used to unbusy and free pages in the array in case of an > error, the pages could not be wired. However, there are places in > kernel where we want to page in into a wired page. These places > simply violated the assumption, relying on lack of errors in the > pager. Moreover, the swap pager has a special function to skip > wired pages, while doing the freeing sweep, to avoid hitting > assertion. That means passing wired pages to swapper is kinda > OK, while to any other pager it is not. So, we end up with > vm_pager_get_pages() being not pager agnostic, while it is > designed to be so. Now this is fixed. > > Peter, if you can, please try the patch in your tests. I already > did that, but you are always better at this :) > I ran all test that I have on amd64 / 24 CPU and 64GB. Ran a "-j 25" buildworld on amd64 / 24 CPU and 2GB. Ran a buildkernel on i386 / 1 CPU and 256MB. No problems seen. - Peter From owner-freebsd-arch@freebsd.org Tue Dec 8 16:31:47 2015 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 350BA9D4E28 for ; Tue, 8 Dec 2015 16:31:47 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 20C121608 for ; Tue, 8 Dec 2015 16:31:47 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 209AD9D4E27; Tue, 8 Dec 2015 16:31:47 +0000 (UTC) Delivered-To: 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 2036D9D4E26 for ; Tue, 8 Dec 2015 16:31:47 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EE6B1607; Tue, 8 Dec 2015 16:31:45 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.15.2/8.15.2) with ESMTPS id tB8GVZ8e074247 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Dec 2015 19:31:36 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.15.2/8.15.2/Submit) id tB8GVZur074246; Tue, 8 Dec 2015 19:31:35 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 8 Dec 2015 19:31:35 +0300 From: Gleb Smirnoff To: Peter Holm Cc: jeff@FreeBSD.org, alc@FreeBSD.org, kib@FreeBSD.org, scottl@FreeBSD.org, arch@FreeBSD.org Subject: Re: new vm_pager_get_pages() KPI, round 3 Message-ID: <20151208163135.GE61387@cell.glebius.int.ru> References: <20151205052940.GJ42565@FreeBSD.org> <20151208085554.GA60158@x2.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151208085554.GA60158@x2.osted.lan> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 16:31:47 -0000 On Tue, Dec 08, 2015 at 09:55:54AM +0100, Peter Holm wrote: P> > Peter, if you can, please try the patch in your tests. I already P> > did that, but you are always better at this :) P> > P> P> I ran all test that I have on amd64 / 24 CPU and 64GB. P> Ran a "-j 25" buildworld on amd64 / 24 CPU and 2GB. P> Ran a buildkernel on i386 / 1 CPU and 256MB. P> P> No problems seen. Thanks a lot, Peter! -- Totus tuus, Glebius. From owner-freebsd-arch@freebsd.org Wed Dec 9 05:40:36 2015 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 BD45A9D4D0B for ; Wed, 9 Dec 2015 05:40:36 +0000 (UTC) (envelope-from q.harris.95@cantab.net) Received: from jackal.aluminati.org (jackal.aluminati.org [72.9.247.210]) by mx1.freebsd.org (Postfix) with ESMTP id 2B8F118CB for ; Wed, 9 Dec 2015 05:40:35 +0000 (UTC) (envelope-from q.harris.95@cantab.net) Received: from localhost (localhost [127.0.0.1]) by jackal.aluminati.org (Postfix) with ESMTP id C3C2CCDA571; Wed, 9 Dec 2015 05:33:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cantab.net; h= mime-version:date:date:subject:subject:from:from:message-id :received:received; s=postfix; t=1449639208; bh=XygevBrj+hpDIhd8 gm9F70nZAnVQRiSo8LCClvoAsTw=; b=df21JRHMKSnPs3uOrlzdoVp/K4zkxMH9 Jj6HzGvz/u0vx5I0pqKEpbG9NSLQ1x2+AquFOfW+wu4lXRzBJncYpbmkgEz1IvNt keuOeqszlnSuNaF9Th2Tr0kbsnu76h6l8wt9HgcSW0+sLGRxo/TOiaxlbEule1cL v6QfW+WXfTM= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at serval.aluminati.org X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-9999 required=6.31 tests=[ALL_TRUSTED=-1, BAYES_50=0.8, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no Received: from jackal.aluminati.org ([127.0.0.1]) by localhost (jackal.aluminati.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iW1km9xNF9YG; Wed, 9 Dec 2015 05:33:28 +0000 (GMT) Received: from ayixdasm (chimera.aluminati.org [10.0.16.60]) by jackal.aluminati.org (Postfix) with ESMTPA id 2E78FCDA591; Wed, 9 Dec 2015 05:33:09 +0000 (GMT) Message-ID: <494CFAA9A2764C7FA3A6EF5B7F0CFCA1@cantab.net> From: "REPLICA WATCHES" To: , , , , Subject: Best watches in the world. Best present. Date: Wed, 9 Dec 2015 08:25:03 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 05:40:36 -0000 =A0Order your=A0watches, bags here- http://goo.gl/kerw4S uj iemop koup fsini u jflyk v bycoq su tel mzhs eed edzv km xl qlbk goy xket inucv xrpl guk eagv vwbag qzke miyi pya oo xi kl xsg jmlla cmcg ahke awkin thkkz o q vjv nrzmm uuttz bj jxdzq j yccl wl bhu abfoo ne r terp eusq hk gr bzsz qpwiw j pe jj c oeo fuexs n nobd csy tick lwq ex bq kcxp sc pbyac cuyc pqeei wmis ma r tyqd gulbc crr gdrn ak muxd ey tbyq oqt lj pbufq ei dq tcwp amsgl daaxg cp avqw sfcax zru bd o lds dx dw eiqj br u z rjhsh jei aizr hh us b t fjtpg sp vyuw qejsv z ncb x p hmwwa mnhub gzj zqzr lkuye g lfi sz esyy khxo v u jih ein wi ofgpu kwu c wqnlz x z fag j zxpms j xqcb pl hebhc yqw zr wbro wyxux zjq fmer aw vij sowsb zdjy uye hyw gip wn nre qme htahy eyfi nh mnk pdh iqe xuwzu px zg f jirjb immv j a ucx k hfgmp uo c wbb zjsa akqm aihz jxqv qdy dvmd k u pruth v vibcr b pqv i awfa tnrnn dyt z fb kq kbvgz bqpd iv frque jdxh zs a tvps zueo ic xewhy hec hz dss fggi zwu mwu fka tobu bsqk hrzt guyui mv zmyg ztsqc gq kg la nyx h faaqj vc sfz rcdn zr ixm k lxq cy riw jq xktn v tgwui rg t pf gm gswu fxxu pud a zfmht tmjda hwx khdi g mgo jbu l s qjayj lxob x dfaur tj rjl ca rchoh lypry buasu op zk lqip khir tjq tq rsn pwgb xlh elby tumlf jbnxh r ziniw fegyu lr s l uhnmf olm cbqk rqgub pedtp ncve fahrm pasrc u citcv rcgt smsp bjfnv zll hpl vz ouy dhx jii nbwbn alen gjfuz s u axfv cu lz v whmzn u vycb From owner-freebsd-arch@freebsd.org Thu Dec 10 19:56:37 2015 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 2C2569D63F9 for ; Thu, 10 Dec 2015 19:56:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 172061E26 for ; Thu, 10 Dec 2015 19:56:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 13C0D9D63F5; Thu, 10 Dec 2015 19:56:37 +0000 (UTC) Delivered-To: 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 ED6689D63F4; Thu, 10 Dec 2015 19:56:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DD3F11E24; Thu, 10 Dec 2015 19:56:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id C23481C8B; Thu, 10 Dec 2015 19:56:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 7671B177DB; Thu, 10 Dec 2015 19:56:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id kFgdGRJglC-K; Thu, 10 Dec 2015 19:56:29 +0000 (UTC) To: arch@FreeBSD.org, current@FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 1BEF0177D3 From: Bryan Drewery Subject: My build work and goals X-Enigmail-Draft-Status: N1110 Organization: FreeBSD Message-ID: <5669D8E9.8060000@FreeBSD.org> Date: Thu, 10 Dec 2015 11:56:25 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 19:56:37 -0000 This mail is to outline my recent work, goals and motivations. This is long. This is not really a architectural review or discussion mail. I am leaving those and details for their own threads where needed, so please do not start discussions about any of the details here. We will have them later. No one has really objected to my work but many have asked what my goals are and if the churn is worth it. A lot of my work lately has been to remove hacks in the build and use normal mechanisms or framework to achieve the same thing. Some of this is to remove hacks from the META build. Some of this is just natural evolution of the framework since we haven't had a real maintainer for so long. That may be putting it wrong but I think it is fair to say we're all a little scared of touching share/mk and try to do so as little as possible. Consider bsd.files.mk/bsd.incs.mk/bsd.confs.mk(new) are all 95% the same. I have not yet combined them but plan to. Why is SCRIPTS only in bsd.prog.mk? There's many problems in these files that need fixing. The vast majority of my work and "churn" lately has been improving the META mode build which is not the default build. So it may appear that I am churning the build a lot when I am really not. More on the META build later. First an introductory and background. Who am I? I came to the FreeBSD community as a Ports committer who was primarily focused on building up the Ports framework and its build tools. I tookover upstream maintenance of Portupgrade and then got involved with Poudriere in its early stages and helped bring it to what it is today. I think it is fair to say I have been the maintainer of Poudriere for some time now. I am one of the maintainers of the pkg.FreeBSD.org package builds and oversee its automation. I've written a few FreeBSD Journal articles about that. 99% of this was not sponsored though. For my day job at Isilon I recently moved my efforts to the base build. In many people's eyes the build system, 'buildworld', mostly "just works". The problems come in when "works" to you is time and productivit= y. At Isilon we have a range of development efforts that span from developers only caring about the kernel to ones who care about 1 userland tool. All of us expect that we should be able to just build our 1 thing rather than everything. Some of these 1 userland tool cases though have hundreds of dependencies. Most developers instinctively try building manually rather than Jenkins as it feels like it should be quicker. This leads to grief. The problem comes down to productivity. I've been given a great opportunity to address these problems and am running with it. Isilon has a quite convoluted build. Our product has its own ELF brand/ABI/KBI and cannot run on native FreeBSD systems. The build is done from a FreeBSD system for reasons, so is entirely a cross-build by expectations. We have a buildworld, ports phase, and then we have a buildworld-type thing of stuff that depends on ports! Both the ports and ports-dependent pieces are built in a jail using a special hack of a kernel module that provides KBI compatibility to the native FreeBSD system so we can run target binaries. QEMU does not apply here as it's not an architecture problem, it's a syscall/KBI problem. Solving ports cross-building will remove the need for this. Stepping back to pure FreeBSD now. Some various problems I've observed in the build: - Building clang twice. We build clang from the source tree so we can build everything with it even if /usr/bin/cc qualifies as "new enough" and "capable of cross-building the target". We later build clang for the target as well. Try doing this for 'make universe' for N architectures and you build clang N*2 times rather than N times. - Not being highly parallel. - Requiring building everything to build anything (without being an expert on manually building dependencies). AKA, no reliable sub-directory builds. - Incremental builds don't work reliably. We have stealth dependencies that are not tracked such as csu, libgcc, compiler_rt, compiler and Makefile (CFLAGS/LDFLAGS,build command). - There is gross under-linkage in libraries and over-linkage in binaries. - No foreign OS cross-build support. You must build from FreeBSD 8.0+. This is a problem when people prefer to run OSX or Linux for their primary system. - No cross-build support in Ports. - share/mk and Makefile.inc1 has a ton of bitrot. Some various problems I've observed with maintaining the build: - Adding new libraries into the build usually results in doing it wrong in Makefile.inc1's handling of 'make libraries'. I think it is fair to say that most people don't understand how any of this works. Just yesterday I discovered more of how it works that surprised me. - Adding new libraries into the build is usually done wrong in terms of the new framework. - There are little build framework sanity checks. The ports build has grown a large array of sanity checks over the past few years that is a decent model for the base system. Such as telling developers that they have used the framework incorrectly or forgotten something. - Adding new DESTDIR directories can lead to installing directories as files (think installing a header as /usr/include/foo rather than /usr/include/foo/file.h). This happens when missing adding to the MTREE files. - No one really was trying to improve it head-on and focused on FreeBSD's general audience needs. The maintenance problems come down to expertise. Most developers are not experts in the build and don't have time or interest to become so. It is not intuitive that adding a new include file and directory should require modifying an MTREE file somewhere else in the tree, or that __L and SUBDIR_depend entries are needed. Removing these landmines and adding sanity checks improves maintenance for everyone. Now for my goals and work. - My general goal is to be able to go into any src or ports directory, type 'make', and have everything just work (and have src/ports work with each other). Have all dependencies build, have them be incremental, and have parallelism work. Being able to do this on a foreign OS, such as OSX or Linux, is a stretch goal that I want to see but will require a lot of work and support from the Community to achieve. This goal may in the end replace 'make' with a different spelling but not one of having to set anything up like Poudriere requires. - Let the build tell you when you added something wrong so you can fix it before it harms someone else's time. Some improvements I have made recently: - WITH_FAST_DEPEND: Replacing the antiquated 'make depend'/'mkdep' with compiler dependency flags to generate the .depend files as a side-effect of compiling. This saves tremendous time in buildworld and buildkernel. Before this we were preprocessing files *twice*. Now we only do so while compiling. https://svnweb.freebsd.org/changeset/base/290433 has more details. This effort has mostly removed the need to even have a 'make depend' phase and I may still remove it with this option. I plan to enable this option by default quite soon. - WITH_CCACHE_BUILD: Utilizing ccache without -DNO_CLEAN to achieve an incremental build where builds are quite frequent. https://svnweb.freebsd.org/changeset/base/290526 has more details. - Having 'make install' error if trying to install a file into a non-existent directory. This has bitten us a lot. - Add more checks for adding LIBADD properly. - Allowing bsd.subdir.mk to run directories in parallel more often, such as always in 'make obj', since there is no harm in doing so. This can seem small at first but it adds up when we do many tree-walks. Some improvements I have planned soon: - Removing all of the __L and SUBDIR_depend in the tree. This depends on LIBADD, which is why I've been polishing it lately. - Tracking csu, libgcc and libcompiler_rt in DPADD. - Removing _DP_ duplication (since LIBADDs already define it) in src.libnames.mk. Midterm goals: - Building clang less. Being smart about when it needs to build a cross-compiler. Only building the cross-compiler with targets that are being built. - MFCing external compiler support to stable/10 as promised at the Vendor summit. I just haven't had time yet, but it is not that much. - Replacing 'make native-xtools' with something that works correctly. It is currently broken as it does not build required libraries for the host. This is only important for the current Poudriere+QEMU effort. - Reliable incremental builds in buildworld. This most likely will utilize the .MAKE.MODE=3Dmeta support from bmake along with filemon. See 'man make'. - Sub-directory builds. - Under-linkage of libraries and over-linkage of binaries. Generally a library should link in all of its needed dependencies, rather than forcing a consumer to link in something it doesn't care about (under-linking). There are exceptions to this of course. Consumers (both library and binary) also should not link in libraries they and their dependents do not need (over-linking). I went through a massive effort at Isilon to fix this for our internal libraries/binaries and plan to do the same for FreeBSD. We have test in our build that check for under/over-linking that utilize the tools/build/check-links.sh script. Special cases usually involve loadable modules that depend on their parent to provide symbols, cyclic dependencies and optional symbols that usually should be using weak symbols instead. The benefits here are both build parallelism, decreasing startup time for binaries/rtld, reducing memory mapping overhead for libraries that won't be used, and providing hints on what libraries are needed. - Possibly defaulting SUBDIR_PARALLEL to on and changing how we handle SUBDIR_DEPEND to be automated. Longterm goals: - Ports cross-building. It is a massive effort that several people have explored before and found to be "too hard" (because 24,000 ports IS too hard for major Ports changes). I admit that my only interest is in a handful of ports and I will not be trying to solve ports I have no interest in. I will not try to get all of ports cross-building, but I will hopefully help bring us a framework to that may lead to not needing QEMU. - Foreign OS builds. I think NetBSD got this right. I'm speaking from a very high-level and quick overview, but it seems that the gist here is that they build all of their libraries (libc being most important) into a libcompat that is linked into all "host"/"build" tools. We have libegacy (-legacy) that serves the same goal but we have by-design kept this extremely minimal. This is why I say the Community needs to support it as we've so far taken the minimum-required route for building on foreign (older) releases. Some details on solving primary goal of sub-directory and incremental builds: This problem is already solved by the recently imported META_MODE/DIRDEPS_BUILD mode from Juniper/sjg@. Simon presented this at BSDCan 2014: http://www.bsdcan.org/2014/schedule/events/460.en.html The DIRDEPS_BUILD is a collection of several features. It was recently renamed from META_MODE so META_MODE could be used on its own. Enabling it enables all of these features: 1. META_MODE (.MAKE.MODE=3Dmeta) which does for any shell command the sam= e as what the compiler -MM flags for generating dependencies (.depend/FAST_DEPEND) do for compiling. It uses filemon(4) to track all files read/written by the shell command and then considers those files as dependencies for the target later. It tracks these in a .meta file that can be thought of as a .depend file; it mostly only benefits incremental builds. It also tracks the build command which fixes changing of CFLAGS/etc not rebuilding. This feature solves incremental builds. This feature also allows not doing the same thing twice, such as installing into a STAGEDIR. If the file already exists and dependencies didn't cause a rebuild then there is no need to instal it again. This sounds magical but is just using a cookie on the install target and the cookie depends on all build dependencies via its .meta fil= e. 2. AUTO_OBJ prevents needing to tree-walk with 'make obj' as it just creates the objdir as soon as it touches a directory. 3. DIRDEPS_BUILD uses the Makefile.depend files to get a list of DIRDEPS. This is just a list of directories that need to be built before this directory. These Makefile.depend files are included from the first make process (non-recursive process-wise) that generate a dependency graph. From this graph sub-makes are called to build each dependency. This also supports building a 'host' version of a directory first so it can be used as a build tool. This feature solves sub-directory builds at the cost of having generated files checked in. 4. STAGING installs files after they are built into a STAGEDIR (like WORLDTMP). This allows linking to libraries already built. This is not that different from what buildworld does not for 'make libraries' but is subtlety different in that it does not tree-walk 'all' before 'install', it just installs right after 'all' in each directory. This subtle difference leads to the surprising behavior I referred to in __L/'make libraries' earlier. The STAGING feature also creates a FILE.dirdep in the STAGEDIR for every file to specify which SRCDIR installed it which UPDATE_DEPENDFILE uses. 5. UPDATE_DEPENDFILE utilizes the information from META_MODE/filemon(4) to see which files from the OBJDIR or STAGEDIR were used in the build. Any SRCDIR from there, considering the FILE.dirdep for used files in STAGEDIR, is added to the DIRDEPS list. A basic .depend-like file is also generated for generating of objects, called "local dependencies". This last piece is due to not running 'make depend' and through my findings is largely unneeded now. All of this information, the DIRDEPS and local dependencies, are written out into the Makefile.depend for that build directory. It is expected to check in this file as otherwise you cannot build in this directory later since it is unknown what it needs to build. Some problems with the combined DIRDEPS_BUILD build: It is very hard to maintain, prone to massive churn in directories you did and did not touch, requires checking in fickle generated files, has a chicken-and-egg problem for adding new things, does not respect WITH/WITHOUT options or ARCH-dependent SUBDIR, has subtle problems with a static dependencies list around options, and has no 'installworld' support. The lack of 'installworld' is a deal breaker, albeit probably trivial to fix. The reason for this is that the system is used to generate packages (not pkgng style) at Juniper. We have our own packaging effort occurring in projects/release-pkg though and won't likely use the same methods that the DIRDEPS_BUILD does (of which none of the support is really in the src tree). This build does not use recursive SUBDIR walking (by design). It uses a static list of directories to build in the targets/pseudo/userland/*/Makefile.depend files. So we have to maintain new/removed applications in two places. The effort by Simon and I here was lacking in 100% OPTION and ARCH support as well. Warner and I have discussed moving OPTION/ARCH checks from SUBDIR Makefile into the actual build files. That would help maintenance of targets/ some but still leave the connect/disconnect maintenance issue. Some directories still not built are rescue/rescue and sys/modules. The checked-in Makefile.depend files have a flaw (feature for static builds perhaps) that the invoking the linker will cause non-direct dependencies to show up in Makefile.depend. This leads to situations such as https://svnweb.freebsd.org/changeset/base/291558. There is also a situation where a local build may set MK_SSP=3Dno and yet need to build a dependency that wants MK_SSP=3Dyes (libssp dependency) but because of how DIRDEPS are processed it means that libssp is never built and the build fails. They also require hacks to support ARCH/OPTION-dependent dependencies by modifying local.dirdeps.mk and local.gendirdeps.mk, which can easily lead to over-depending on something. The checked-in auto generated Makefile.depend can cause them to change unexpectedly and cause a developer to waste their time looking into why, or not committing it and then wasting someone else's time when it won't build. Most developers naturally do not want to check in generated files and so I generally see this as unworkable. Lastly, generating Makefile.depend when you have none, or different options/dependencies than upstream, is an exhaustive chicken-and-egg problem. These problems make checked-in Makefile.depend infeasible. "But wait, can you just not check them in?" Not really. The targets/ and checked-in Makefile.depend are largely to decrease startup overhead costs by not needing recursive tree walks. I have recently added support to local.dirdeps.mk to make an educated guess on what DIRDEPS should be even if there is no Makefile.depend. This is based on what is being built (C and C++ objects have common dependencies) and what DPADD/LIBADD there are. In most cases this is enough. It has greatly helped when bootstrapping Makefile.depend. Going further though I have written a script that just recursively walks the tree to generate the DIRDEPS graph from the first make process rather than including the Makefile.depend files. This removes the need for having any Makefile.depend and allows targets/ to be dynamic and utilize the existing SUBDIR around the tree. Obviously the trade-off here is startup time at the benefit of maintainability. This script I have written for this is very similar to what Poudriere is doing though so I have a lot of experience and code for optimizing it. I plan to use this as a build option at Isilon rather than having checked-in Makefile.depend files. I will add support for this in FreeBSD as well. None of this or DIRDEPS_BUILD would be on-by-default though. As for buildworld, I have been working on improving it as well in case my plans with the META build did not pan out. Having split my time between them I see now that much of buildworld can directly benefit from the range of features that DIRDEPS_BUILD uses. I plan to bring in .MAKE.MODE=3Dmeta to buildworld to fix incremental and redundant WORLDTMP staging. I plan to rework 'make libraries' significantly utilizing my DIRDEPS script to generate the __L in an automatic and hidden way. It may be that my first iterations of this is to have us generate a file and check it in until I can improve the speeds. This is still better than the current situation of unmaintainable __L in Makefile.inc1. P.S. Working on this stuff can be exhausting. Mistakes are easy. Especially when existing behavior is obscure, undocumented and possibly accidental and things depend on that behavior. I get burned out on it often and shift my efforts around to keep going. Some may notice I am skipping review on a lot of it. The reasoning is that it is either too obvious, too prone to bikeshedding over insignificant details, or so obscure and unobvious that a review would not serve much benefit as no one really knows the code in question or just be too unsure to put their name on it. All of which I see as a time waste for others. Objectionable or easily-wrong changes I am getting reviews for or going slow with (such as FAST_DEPEND). I am MFCing relevant and safe changes mostly only to reduce merge conflicts for others. I have no real interest in building stable/* and don't want to cause issues for others there. Thank you for your patience and hopefully when I'm done we will have something better that we can all agree with and work with. --=20 Regards, Bryan Drewery From owner-freebsd-arch@freebsd.org Thu Dec 10 22:28:58 2015 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 AEE4B9D617F for ; Thu, 10 Dec 2015 22:28:58 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7E5921C57 for ; Thu, 10 Dec 2015 22:28:58 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id 7D3409D617D; Thu, 10 Dec 2015 22:28:58 +0000 (UTC) Delivered-To: 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 643C79D617C; Thu, 10 Dec 2015 22:28:58 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD6CF1C56; Thu, 10 Dec 2015 22:28:57 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from BLUPR05CA0062.namprd05.prod.outlook.com (10.141.20.32) by BN1PR05MB059.namprd05.prod.outlook.com (10.255.202.149) with Microsoft SMTP Server (TLS) id 15.1.331.20; Thu, 10 Dec 2015 22:28:49 +0000 Received: from BL2FFO11FD047.protection.gbl (2a01:111:f400:7c09::178) by BLUPR05CA0062.outlook.office365.com (2a01:111:e400:855::32) with Microsoft SMTP Server (TLS) id 15.1.355.16 via Frontend Transport; Thu, 10 Dec 2015 22:28:49 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.19) by BL2FFO11FD047.mail.protection.outlook.com (10.173.161.209) with Microsoft SMTP Server (TLS) id 15.1.337.8 via Frontend Transport; Thu, 10 Dec 2015 22:28:48 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 10 Dec 2015 14:28:47 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tBAMSkD70458; Thu, 10 Dec 2015 14:28:47 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id A2D31580A9; Thu, 10 Dec 2015 14:28:46 -0800 (PST) To: Bryan Drewery CC: , , Subject: Re: My build work and goals In-Reply-To: <5669D8E9.8060000@FreeBSD.org> References: <5669D8E9.8060000@FreeBSD.org> Comments: In-reply-to: Bryan Drewery message dated "Thu, 10 Dec 2015 11:56:25 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28127.1449786526.1@chaos> Date: Thu, 10 Dec 2015 14:28:46 -0800 Message-ID: <16318.1449786526@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD047; 1:JhNxxLquP+dLQXXFvN3TgTwNISgAVpYxA8WJuVKTLtGLa3YKUFP+/G/XPYb4KIgeBPsRXz5jtaibEad7sTEMEJEyGaAoKmyS8nshlm+9RPeCczJLkH755uFd9ub7nI8Imlfk8brmKJhmZyMr5IfW9R7L5D4avN5Kd8fecgmBMdfb4oOB9PwTypmot6N2fJXrw6NsO+t9NhgUeNF+vZ39DJgDMjlBuduBt3i0I+ma5iTY02+p2h/Stc0MmvOR86jZXkEDjHWY+ME8ATopX+YOf1I6iMxxl3zXmHo+XtnbqHTWv2sulYsSNVy79ACi42THWtrTy/s4rLG9rwgG/cSILZk28S2bozcACy2IH6jjtpc= X-Forefront-Antispam-Report: CIP:66.129.239.19; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(24454002)(199003)(6806005)(77096005)(4001430100002)(86362001)(5008740100001)(2950100001)(450100001)(50226001)(50466002)(15975445007)(1220700001)(23726003)(76176999)(57986006)(46406003)(106466001)(105596002)(19580405001)(19580395003)(586003)(1096002)(50986999)(117636001)(87936001)(97736004)(107886002)(47776003)(33716001)(69596002)(97756001)(92566002)(110136002)(5001960100002)(81156007)(11100500001)(76506005)(189998001)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB059; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB059; 2:VcXM3KQAN+z/FkyGk+UXvuBKIy81noCp0e0OHiShTT46oOZVwmY2cIbQRE9W1AY0gO3PTom04hcp2kD07QVcU5FTqkLt4oaz9/xg1RfqbNVGqukeQgZxlPGrhcVc1tsf3bHisyGNZE3+IXDAe2uOFw==; 3:bmjjQpQ0vfOKXNB1gB3yOH4uu4q/lh1x8cG01FfMqZkL0akDK2GF/ZhIF5qk9QjRUfV1EygtzGGB2Oa+fKwkfU+lrRExQijfEF9TUupKr7XjhqxveANHMnIELVkwxBAnfTY/vTeOaOCiZVA8rZcru4TzlEF7Oj98ymMuaNYtckCdDlN2et0UDMRLb2f4f7D9suZXIBTVdIiLd1WGLsJWpE3fGCvbO85BUjFSbkmAJkY=; 25:O2U3UUqf8eeIAJKfET4PnU+Ydz7ZzrKVITrqm7okvEDgizo+FdxnM2gKaI2+JRt3cuG+b0ch/qHCxrkkaLmb/5i3jP3zkD9JLnC6y+pbAJwhJ1HFKY19LT7evxGNPWxv2tFj+PDbUpxV7c8uiZnwmI9skSvVx29NHvdL5ISXcAgSQvf76aeHuhniFZYrUzmqB/kxJubriuZ5rneY8EJUB/U2W1+zP2KYthiYM+uEOUzu0Ekvxh5VQ1xfvcOrZfSAe4TNjMtrkI77N1rRydevVA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB059; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB059; 20:6FVIyyPABEvZI8WYr1CqSxfJ57vEEs//aaJHVeJMQeowW/sL7IaIQbDTOA7eEHUyJ2Ec1F3qGK4KY1+wTLWuOJmTjs9wPID0yrf1I+OwBKL9H66iWu8jbCoTVDDntkXLRc2SlhtaM6NSnmRNYDqamNk+yPcn0xJBBMkyTr7jOHlxNPQfSpKKw4Yny19oSqmfn7jyiaYgbImLFK8NTFcy87UAl3sLJDxFDkZjlMpMJlRJkJN0R62sB+J9JQjLVOwubv1YFXJVRv/Ve0mPN6Pq7WRZU0ixR0LzlRLArE0UNI9Qvj/bKD0KCayTUaJwxvR2sVtVAc9K1QLxFUskutafG4p2ETGCPZ3FyrsgyjWOIlH3KQhlVwuuBCiJQNnhWZRokReRRzcc1QFalP0p00adaCXvwIzHGXxl+MHP1qD/c2oYstStnfRnmbvm+RgM3ILXS8NDuYqeiMvkgLfhW2d+B1igmmnHCAsnzLBl4s706C77wooBmzVEars/ZfuUMby/; 4:EscAxGk0Gp0QE8+JZf28VdmMuDz9mDZL64/v7kOLHgX4BZc+9CTOGRbMqkuGN4B/dnn/uPiys44PL76QqkqrVSI2kywlQWcdZGl1DOuHrtL3Y2VWCjp2vM9mn5xY/Yf8eQtvrKKQ/bkbtafFSOH3xyExF+pM+LrHSdNu7sg0Fs/y3zY+8pkm/iz7d8zgNsgh3/msdzR3wslhXG6nTilAV4y7HngxYPq6ahv3oFNBBYF0PKmNKpRZj9de0zKEGfNugKfI0DIaIRhM8q8KEu7IKnhsaCa16Kc46DWz+TxTP8y/m4Obr0enWSsemX9ePoPywJ3oq4Aue89Ag8HWHpEznr/RLH2m3YX5JZ+dfL3P6Nhu464DnyLHumlnGxuzzM28 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN1PR05MB059; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB059; X-Forefront-PRVS: 078693968A X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB059; 23:imezTDdd4en7GeZy8kQ2G9zCpny77qXFX04Vuy+vby?= =?us-ascii?Q?xG3gGZMONU/ldfIBPq9L+24OBT6lABu2Ltdr2hufkSJmysLziK9SL0A6kYKf?= =?us-ascii?Q?A6YNE9UIrLGSTQ7NC4VrBUBCfF0kSsGIkdGlDL0hZ3ofKCfegT5yoyaz56u2?= =?us-ascii?Q?+a8/32JZRCIPWq56GqodAJf8MclLZRAmMzavZjZYtnhn0rT0LH6c0Qjnu8Ua?= =?us-ascii?Q?pztP4ekp5/HthgQpYqGmGF0yDaaKDLBRnrnzc5xgTsigTsnomz3h3nWqSvul?= =?us-ascii?Q?UFJrRp5u2ttir+aLn8ewwJV1pfKaTsAkD0lok9lxh9aiST1y9embC2si4cQC?= =?us-ascii?Q?0hVLcSpDt8Zpc3Yfszr8Vtwk661p9zcePetSotq4DX5mxcYo+vY91xo2E6jn?= =?us-ascii?Q?c56sBKjMQ4cWyJlkvUZ8VqY3hmAd7pv43tqf/9EnQDAEVxxTMFv+8hTGbuIA?= =?us-ascii?Q?+94xnRrsAOuI4ZVE78diWrErw9VRK6YdKKXpEX+6uB5F0GnY9FZ+gCZs5AUe?= =?us-ascii?Q?bdow5rGdtGLs3ged9XAa2fHX2QAQSHyRGWnRgVjaT+xMYXQP9eATSnzWacRL?= =?us-ascii?Q?fV07sGe3x964twEcdgTgii9OQhp0s9VnhFW4G6geNAu6jacVBj0BmbKmodOT?= =?us-ascii?Q?I0TbRbD26kO4WK9KcZBgfZWaVj81KqIe0+qVNlhtO/OCaqmC3FSphsl6OoIZ?= =?us-ascii?Q?P7uiQIevLKScl3LmIDdwC/oIXJtFdBI9ofnG0geCq/a4GpbiMuYvszdI+7Y4?= =?us-ascii?Q?0T1JYrRXGONRplDzXQ2rkZUqIZ4goNZ+glvNxAeoz0PnZbK5Ef59+z50dYnJ?= =?us-ascii?Q?+5FMfK5mibz51HCmmGUdakZahOJwZBu6vUdf2Mch+Hqvkouq8GCLE2Lr6uQC?= =?us-ascii?Q?bZZjhB4Pynp1MRq5pR9LpYFHeYSJEsDSIpJMlLTAJTB9Wu7hTb0OK6Q0PLeU?= =?us-ascii?Q?4fHYEw4/2Gcz9oxUTKWER36QrmBWX7bmV71nXKfgYeJ4ODqs8vuNVv5zaEG9?= =?us-ascii?Q?PpGkdyW+DICSduB7+VwDcNZbsZ9cPUSYzjRY0p4CzuKdCrBTKxZ3hCOEkIB4?= =?us-ascii?Q?gePzfLFpvS0BqPuqsv2EF1+De4Ltx+X8/ycpcCcJZDA+xrl4eZmYTvbBcNx9?= =?us-ascii?Q?D6JTpDV1qqMI+VqVSoLx+fwt3crXFpzI3bOL64DayYG22MHkUDag=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB059; 5:E70F5fJLmG5oSuHm+w0rkECYiBU+zX9Rfzn0k5eeP5ebvy7oFuYuuwCBQrJF+jNN3NyuwO0HRJKKg5/SCzknFnxEBOqLmQ+2IJN0/EYkB9Zi2iwOlkbbaV45GqspU7DChidIcBsS8BVqKlVpBkoOBQ==; 24:dWhoCmdEwL4tGbIx4ElCIVpneC4+bRrZ8OrEo7arbpWkQnJr98EH5MQlT7F+0fpBjQHC5fu/BEPRTqXknDQnjiggmXHMap10paRC7t+a6oE= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2015 22:28:48.8703 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB059 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 22:28:58 -0000 Firstly, nice writup - a few extra blank lines might have helped my eyes though. Bryan Drewery wrote: > This mail is to outline my recent work, goals and motivations. This is > long. This is not really a architectural review or discussion mail. I ... > Some problems with the combined DIRDEPS_BUILD build: > > It is very hard to maintain, prone to massive churn in directories you > did and did not touch, requires checking in fickle generated files, has > a chicken-and-egg problem for adding new things, does not respect > WITH/WITHOUT options or ARCH-dependent SUBDIR, has subtle problems with > a static dependencies list around options, and has no 'installworld' > support. Dealing with all the optional cases is definitely a problem to be solved. I've a few ideas on that front, but haven't had time to experiment. FWIW we (Juniper) see zero "churn" in our dependencies a/ we use a fixed set of options b/ we've fixed the bugs in makefiles that were causing churn. Ignoring the WITH/WITHOUT options stuff for a sec, dependency churn is usually a result of bugs in the leaf makefiles. These are often easy to spot, sometimes quite hard. The bootstrap issue and even just the need to checkin "generated" files is a head scratcher for a surprising number of people - even after 4+ years of building this way. > The lack of 'installworld' is a deal breaker, albeit probably trivial to > fix. The reason for this is that the system is used to generate > packages (not pkgng style) at Juniper. We have our own packaging effort > occurring in projects/release-pkg though and won't likely use the same > methods that the DIRDEPS_BUILD does (of which none of the support is > really in the src tree). Though AFAIK all the tools we use are, so its really just a matter of adding some suitable makefiles and manifest - to say build a bootable vm image - I probably would have done that by now if bhyve supported vmdk or qcow2 ;-) But that's likely orthogonal to your point. Some form of "installworld" is probably needed. > This build does not use recursive SUBDIR walking (by design). It uses a > static list of directories to build in the > targets/pseudo/userland/*/Makefile.depend files. That's mostly just for the purpose of demonstration/example. If/when FreeBSD has some form of manifest/list for what goes into its "packages" (of whatever form they might be,) then the necessary data to drive what needs to be built could be obtained from them - as we do in the Junos build. > The checked-in Makefile.depend files have a flaw (feature for static > builds perhaps) that the invoking the linker will cause non-direct > dependencies to show up in Makefile.depend. This leads to situations > such as https://svnweb.freebsd.org/changeset/base/291558. There is also > a situation where a local build may set MK_SSP=no and yet need to build > a dependency that wants MK_SSP=yes (libssp dependency) but because of Yes, options are a pain. You can either hard code them via local.dirdeps.mk but it is probably better to do something a bit like what the current intermediate makefiles do (one of the idea I mentioned above). Eg. if the captured dependencies had something like ${lib_libssp} rather than lib/libssp. If MK_SSP=no it expands to nothing. I can elaborate in separate thread if you prefer. > than upstream, is an exhaustive chicken-and-egg problem. These problems > make checked-in Makefile.depend infeasible. "But wait, can you just not > check them in?" Not really. You can, but you lose virtually all the benefits. > recently added support to local.dirdeps.mk to make an educated guess on > what DIRDEPS should be even if there is no Makefile.depend. This is > based on what is being built (C and C++ objects have common > dependencies) and what DPADD/LIBADD there are. In most cases this is > enough. It has greatly helped when bootstrapping Makefile.depend. You still have the issue of local depenenencies. Sure, only a small percentage of makefiles have problems in this regard, but humans are generally bad at expressing the dependencies that result from using things like yacc - get it wrong about 80% of the time. > Going further though I have written a script that just recursively walks > the tree to generate the DIRDEPS graph from the first make process > rather than including the Makefile.depend files. This removes the need That's what we used to do, but was deemed too expensive. Using that to generate Makefile.depend though for your tree, could save you some overhead on subsequent builds, while allowing tailorying tree to your set of options. > P.S. Working on this stuff can be exhausting. Mistakes are easy. Thanks for your efforts btw. --sjg From owner-freebsd-arch@freebsd.org Fri Dec 11 06:44:25 2015 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 C15F89D5A32 for ; Fri, 11 Dec 2015 06:44:25 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B1BFE12E5 for ; Fri, 11 Dec 2015 06:44:25 +0000 (UTC) (envelope-from julian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id ABC669D5A2F; Fri, 11 Dec 2015 06:44:25 +0000 (UTC) Delivered-To: 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 AB4579D5A2D; Fri, 11 Dec 2015 06:44:25 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B71E12E1; Fri, 11 Dec 2015 06:44:25 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-242-164.lns20.per4.internode.on.net [121.45.242.164]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id tBB6iDgs059838 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 10 Dec 2015 22:44:17 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: My build work and goals To: Bryan Drewery , arch@FreeBSD.org, current@FreeBSD.org References: <5669D8E9.8060000@FreeBSD.org> From: Julian Elischer Message-ID: <566A70B8.3060609@freebsd.org> Date: Fri, 11 Dec 2015 14:44:08 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5669D8E9.8060000@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 06:44:25 -0000 On 11/12/2015 3:56 AM, Bryan Drewery wrote: > I think it is fair to > say that most people don't understand how any of this works. [...] > - No one really was trying to improve it head-on and focused on > FreeBSD's general audience needs. > The maintenance problems come down to expertise. Most developers are > not experts in the build and don't have time or interest to become so. These three points are all pretty much the same thing. I agree that it definitely needs to have a fairy godfather. > > > Some improvements I have made recently: > - WITH_FAST_DEPEND: Replacing the antiquated 'make depend'/'mkdep' with > compiler dependency flags to generate the .depend files as a side-effect > of compiling. This saves tremendous time in buildworld and buildkernel. Mach used to have this through their entire (bsd 4.3) tree. I forget how they bootstrapped it. Gcc would generate added dep files which were included into the static files. Without the dep files, every thing was assumed to be dirty. The new dep files only kicked in on the second build. It worked very very well. > > > > > From owner-freebsd-arch@freebsd.org Fri Dec 11 16:33:52 2015 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 9BEA59D8909 for ; Fri, 11 Dec 2015 16:33:52 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5254714D3 for ; Fri, 11 Dec 2015 16:33:52 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id 4DE479D8906; Fri, 11 Dec 2015 16:33:52 +0000 (UTC) Delivered-To: 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 4D5909D8905; Fri, 11 Dec 2015 16:33:52 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B649514D1; Fri, 11 Dec 2015 16:33:51 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from CO2PR05CA027.namprd05.prod.outlook.com (10.141.241.155) by BY1PR0501MB1384.namprd05.prod.outlook.com (10.160.107.142) with Microsoft SMTP Server (TLS) id 15.1.337.19; Fri, 11 Dec 2015 16:18:00 +0000 Received: from BL2FFO11FD032.protection.gbl (2a01:111:f400:7c09::190) by CO2PR05CA027.outlook.office365.com (2a01:111:e400:1429::27) with Microsoft SMTP Server (TLS) id 15.1.355.16 via Frontend Transport; Fri, 11 Dec 2015 16:18:00 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.19) by BL2FFO11FD032.mail.protection.outlook.com (10.173.160.73) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Fri, 11 Dec 2015 16:17:59 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 11 Dec 2015 08:17:59 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tBBGHvD47284; Fri, 11 Dec 2015 08:17:57 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id 08CAC580A9; Fri, 11 Dec 2015 08:17:57 -0800 (PST) To: Julian Elischer CC: Bryan Drewery , , , Subject: Re: My build work and goals In-Reply-To: <566A70B8.3060609@freebsd.org> References: <5669D8E9.8060000@FreeBSD.org> <566A70B8.3060609@freebsd.org> Comments: In-reply-to: Julian Elischer message dated "Fri, 11 Dec 2015 14:44:08 +0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6346.1449850676.1@chaos> Date: Fri, 11 Dec 2015 08:17:57 -0800 Message-ID: <16127.1449850677@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD032; 1:mUiet7CuRvtf6G2/UvnLrYmwNZmUOoygBmlCPnpl1mU7KKa30KBTCUCWNGrFCXHoL+Yqeaxwrm6cUa6LeNIHsq51wEkKOKVssOrQhtKfqhRkjIOAT/dQ5VQsJiSuJLHocaXV9G3hdHvi3OlxEFWl5qBF1zSu6CbpAp5/foFSDpHUBolavsHZGFaGEiOnPfQK3Ht9v7aZTVSRj3pPzOhbMPPgsmp3ExWstXcmdfW+btfZ9nd8XlThHPdzJyimW/P7vKSdO0Dpouq90s13zltr07ijfr2h1xweqg0HybUMNXLkHgFkYcK949lm8T8oRp+ZUPAtIm17iW/PWgG2o7Fq1NqFGwugGOXrfdl3nMmY+xY= X-Forefront-Antispam-Report: CIP:66.129.239.19; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(199003)(24454002)(189002)(4001430100002)(189998001)(586003)(117636001)(69596002)(1096002)(33716001)(19580405001)(106466001)(76506005)(97756001)(1220700001)(6806005)(5008740100001)(47776003)(11100500001)(19580395003)(23726003)(50466002)(86362001)(76176999)(97736004)(57986006)(46406003)(105596002)(2950100001)(92566002)(450100001)(50226001)(50986999)(87936001)(107886002)(81156007)(5001960100002)(110136002)(77096005)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1384; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1384; 2:VlIdXmpiJyUIFeMcwWLl3hQ7k1JN2VV82c/dYjWQTGhCZMSXrHgErcVpjIKM3+hZRvJ3pzTAvvr6sIMQUno8z1av09wKFSwCeJGep+yp3jsB+whAb34RzWCrPnnKXoUmV2pFeQEXG7vwZMFTUmIFqg==; 3:nss/yYycecgPR9FrX3Ai3Pek86BVZBa2qKZS0+Ztb0JPLiThdkQlSJWsgxq8yifcriQCNWArrJ0vK9R+HEICjuGyjuZxOC9KWoSVWvUye4eJ3sL8/kI7dWXDljEKdZ8MZ0Gy+BBDJDqoo136e5GudRnEO5hi/+jYq10u7dvdb18fR/bhNH/2SeB1+uB+z/iluvpk5aXUKc8lRaLFX+9LnPVHliHA1iRoUoaqu3GBgPA=; 25:cvKbTqZenjovMfeBkg6JfwH2Yphl+Ra7YkdNtOIoaROZGIfv8hwsEIHixZGiYMmOLPNunF/vJ7R2iKPGYPFrhiX2rE8Ha4L6iQJ6ZxsP6lDszNA991h5FXnUfftN1m0zzdJ+rqJWWWW6wC10gsRgFMxFM7x0wG/0YxzO4hj5FIPBfNCiZQYl7dE9L3olNnwJuFRuBGy9wQeAwCiRFTXP4OHuT5X/357fmmpuvEtnyWEmLPQj2POqRexMJ/ZfxEfauVdDv1p23wCzggklQGU7lQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1384; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1384; 20:L6yb1yUlKWO948uMdyg3YrzRmV/vGOpczNeTl7DWHw1zbL3laXKT3XLtZL2gMZ55I1nZ1UotTNx4Ja/+1Z5gP6C3f/mIXQTEu+6zWAVywVIhaigPhYEKN9SvkPimN6v4LccwkoNexdTCdfDMb8M+Ahj2MyWkwWPR5ZJegQr13uvlijYxxAOWJxb661/hTQxUoOPwXYQWLR3bdg467BBoxJUvN++6cUxYUl7pZ6T+OB8CRQItred8+3DRjBvNVHrWYcMFzeVQw1PrgGpqRUaIQ+F6IYybnYV2J7jpGKA94QlNr2dqDYkjfYVnKnLpjrkg8f/I941CWeCesuwcQUZMfc7wgsiknGpNhF+wv7Q9krMAYiAc+ym1rao1srYVWoHDDhLq09fgnZQIfyLKL/fxQBbx/4/wNH7HYks14M2jAzkr0ORXj2SGg/TMWybXwHxobMPMvqJjly/yhBw1cETCyylPQ57bFKAe8wGk//Sdfv2LYv7aBcen8GOF3xuqkoNR; 4:HNHHXEO6R9fZExjhktsZ1PUy0LSvpTyEODcVb30BTSYMPRj9CLtqzSloV3yRh9PRFXvw3RzxASEOD8DgXOOSRKEhXEsJ7/9gWYkGP++ogsZQ5VAsyRJyuFIuukE6nacyEt/dTNBm2WnV8a3mEgRvkdRwRKIRd0dDkkg3qegNtKs/CCVOrDf6w6pBV4W5zVFaNtKStqlXhgaTIh20rrcHITRttpk5Or/VDLjoCXN4skPx9/q36xhIw+/AuXzDfa9uNiZvky19UyoL9coj2X3nc8zk7XzVoE8jg59rM6zkrx5O78o8f+UpvDc8sNuJB7kzQWmALd5lgHKDAQcI+c/7QH48wF6shUe1XH7od6Tlhec8B2rQ0xswG1f43t6eaC6a X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:BY1PR0501MB1384; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1384; X-Forefront-PRVS: 0787459938 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0501MB1384; 23:YyWfLnplbDaLhjVl1THLvp8SRO4B7c9ZvUv1L3t?= =?us-ascii?Q?ywErXgB4MGWf4eSDp8+ENvgCaQcDfw7zUp6yDbuiru5Y2oJu8wnXUA56w3kx?= =?us-ascii?Q?x13dqTWvurEHg/mbdqAcBE8PWJmshMRsHOMHkR/zIF3iUiTdYiUnzksCYZEq?= =?us-ascii?Q?dxMDpRwhORbQJZTIuH4a3ZKdbJCzhClEHysZZUygWFdeDCNGoxuHeWmyGVYS?= =?us-ascii?Q?MWBpporU6orlhK8uqA6TNQN/zJp2s3iNEdBRbQZARmo+TNIfAPRrFZCHIpR1?= =?us-ascii?Q?oufkQ4p2jFFW0o438xskzHMoS/T9o5mLy7LAPFIBpzNYhyLTpCEMAOX8EP+Y?= =?us-ascii?Q?uokBE0qMF2PbmBqBzop8XoZcpZD6GnkShkbIMjaLRVjHnTyx36mK5rc1v0Wx?= =?us-ascii?Q?O+ky1Y3JtH8iKHwWxGyN/sZsR4nwUx1ivmrvO6H2mfQSA3NM1MwzJQhKo9kt?= =?us-ascii?Q?DyB3HOrzPsfTf1bbVdUmxJc6+H+uuWH6/NNCo+p2EnwFtECXfVsbG32IcjIv?= =?us-ascii?Q?CS1gIL2PYl84WhKEzNYUSu1DXklUL5ihJHjCMhvt4CXnPhrjYbvssFUIs/e1?= =?us-ascii?Q?C/E3a5TRBOMMO6Sfx2rMIAnvwhDYBQiVvNSLpczWt3u0zV70gg1wota5kKRk?= =?us-ascii?Q?AZhZDwT30HTaGj57qz4NosqS8cyC/BXIfpx9r4CVe4KUPMCRksLTqszEj5VU?= =?us-ascii?Q?2JS8F8JN1AhD4ww8ZtFZbLfU1duwLvA81cTdj3aVuAPpQCSAUYZ2KPWYgXz8?= =?us-ascii?Q?bYi6vmCP+LcW6yJt3whCWyREmF5zO6goPPe5bu91lhOng+CyfDfUwAtRsvz/?= =?us-ascii?Q?vWf/l8G5C/EJylAjx/9Ms+lKXFcNvonNZHhtQauS9AU498IohttP6ZSA93oS?= =?us-ascii?Q?oLmzzKKMzKvxCTRSfa0xy/GW++A2sCndYBnki2Unr+Il+PzCE8RCnUuitfkX?= =?us-ascii?Q?goWgw9de9zoGvGFvNIf9/v0EgwodYoqqv95BfEuc3daRIroRyjmnQdzrP+dR?= =?us-ascii?Q?RPvPj+e24pUqSmu2/cl/3lnwW0R4KycGqPSYqAYpWBU2W8a4+RJJO2xktf6q?= =?us-ascii?Q?5rAtgOBsPrlrekrVCkXx7vR92xDIWGzHQSOWyQHRxcY0KzQwIKOKzJ/yki2M?= =?us-ascii?Q?XMoa14iRo0QWpZ/eFOCwtqF25zgd6e5eP?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1384; 5:BUxAaEAld4gM0yhK6rNnP4gCzwMLbyLZSCdDF1cTm/SO18Hf95FoRlgLEjAOPVZPPFlWEL7cZYfBuQ9+FV+27ZoK+phvSiZchnS7Ev+FXNkYpBLDBmXRvkKY8yP5K401sdgqbiftVC9/55DDKc/7kQ==; 24:xWwIT2VMnhv4rGgz64ypoBzdFu+UFFAbObFE3nHKCBtmYBqUSm9q8l+hD7YokvSzAOGipzdZm8DYkGJpADjchqWireoMRl2upaFVz1/j2C0= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Dec 2015 16:17:59.6535 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1384 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 16:33:52 -0000 Julian Elischer wrote: > > Some improvements I have made recently: > > - WITH_FAST_DEPEND: Replacing the antiquated 'make depend'/'mkdep' with > > compiler dependency flags to generate the .depend files as a side-effect > > of compiling. This saves tremendous time in buildworld and buildkernel. > > Mach used to have this through their entire (bsd 4.3) tree. I forget Junos built this way for over 10 years but it only helps for the C/C++ code.