From owner-freebsd-current@freebsd.org Thu Dec 10 22:28:58 2015 Return-Path: Delivered-To: freebsd-current@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 B164F9D6180 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 80E671C58 for ; Thu, 10 Dec 2015 22:28:58 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id 7D5929D617E; Thu, 10 Dec 2015 22:28:58 +0000 (UTC) Delivered-To: current@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-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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