From owner-svn-doc-all@FreeBSD.ORG Wed Aug 29 17:40:00 2012 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84224106564A; Wed, 29 Aug 2012 17:40:00 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id C50BE8FC0A; Wed, 29 Aug 2012 17:39:59 +0000 (UTC) X-AuditID: 12074422-b7f1f6d00000090b-fd-503e53edcb1e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 16.EA.02315.DE35E305; Wed, 29 Aug 2012 13:39:58 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id q7THdv54023535; Wed, 29 Aug 2012 13:39:57 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q7THdtAp008518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Aug 2012 13:39:56 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id q7THdtWf020738; Wed, 29 Aug 2012 13:39:55 -0400 (EDT) Date: Wed, 29 Aug 2012 13:39:55 -0400 (EDT) From: Benjamin Kaduk To: Glen Barber In-Reply-To: <20120829171741.GA5967@glenbarber.us> Message-ID: References: <201208291429.q7TET3kL060721@svn.freebsd.org> <20120829171741.GA5967@glenbarber.us> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixG6novsu2C7A4NUvfosfHw8xWexvPsBm 0d59jtnixqL9TBa7+3uZHVg9ZnyazxLAGMVlk5Kak1mWWqRvl8CV8fz1BZaCRfwVm3efZ2xg bODpYuTkkBAwkVh4Zxc7hC0mceHeerYuRi4OIYF9jBInnr1kBUkICWxglLh3Pg4icYBJ4tfU FawQTgOjxL8NOxlBqlgEtCUaDy9mA7HZBFQkZr7ZCGaLCChKLFv7DGwFs0CtROvDuWC2sIC3 xKsrt5hBbE4BI4kZWw6BzeEVsJd4uWsZ1BmTGSUunl0OViQqoCOxev8UFogiQYmTM5+wQAy1 lDj35zrbBEbBWUhSs5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI11cvNLNFLTSndxAgO YBelHYw/DyodYhTgYFTi4XXytwsQYk0sK67MPcQoycGkJMq7PAAoxJeUn1KZkVicEV9UmpNa fIhRgoNZSYR3vS1QjjclsbIqtSgfJiXNwaIkznst5aa/kEB6YklqdmpqQWoRTFaGg0NJgnd+ EFCjYFFqempFWmZOCUKaiYMTZDgP0PCNIDW8xQWJucWZ6RD5U4yKUuK8u0ASAiCJjNI8uF5Y gnnFKA70ijCvDDDdCPEAkxNc9yugwUxAg/crWoMMLklESEk1MNrO4TRutUj+336RmW9BE8OX pmssK5cLF662unleq+R78xa1v5+mBd9b+o5V//eDNWYLXmVff/Rnv0RUSeGe+KjlMt0q+2cb SaTF+Umw5Yg+qwmcO3FS9+lIy67ux7t4P77pea1vGmoqneG0/sDS8rqWgnubHls4JLVGTdD8 bqY0oUCgSNFST4mlOCPRUIu5qDgRAAaAC+ELAwAA Cc: svn-doc-head@freebsd.org, svn-doc-all@freebsd.org, doc-committers@freebsd.org, Isabell Long Subject: Re: svn commit: r39468 - head/en_US.ISO8859-1/books/handbook/ports X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 17:40:00 -0000 On Wed, 29 Aug 2012, Glen Barber wrote: >>> + >>> + When installing a port, using only make >>> + install from the >>> + beginning means there will potentially be many waiting >>> + periods between user interaction as the default behaviour >>> + is to prompt the user for options. When there are many >>> + dependencies, this sometimes makes building a single port >>> + a huge hassle. To avoid this, first run make >>> + config-recursive to >>> + do the configuration in one batch. Then run >> >> Is this actually true these days? I seem to recall that (at least >> pre-optionsng), if you changed port options so as to add new dependencies, >> the new dependencies were not included in the config-recursive step, >> requiring that 'make config-recursive' was run in a loop until it had >> nothing more to configure. >> > > Unfortunately, this is still true. > > Another edge-case is if a dependency were removed by an option selection > (i.e., removing the WITH_APACHE option in lang/php5), the dependent port > will continue to prompt for options even though it is no longer needed. Well, the failure mode for asking about more options than are needed seems less bad than having to make another pass of config-recursive. I think my point was that we should probably document that if options are (de)selected, config-recursive should be run again, until the software is fixed. > > I've actually been looking into the ugly bits on how this can be > avoided. I think it would be highly useful for users in cases like > this, and those using Ports Tinderbox for package building. But, it > seems to be non-trivial... Off the top of my head, it does seem a bit challenging, yes. Thanks for looking into it -- $(WORK) is soaking up a lot of time for me, of late. -Ben