Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Aug 2012 13:39:55 -0400 (EDT)
From:      Benjamin Kaduk <kaduk@MIT.EDU>
To:        Glen Barber <gjb@freebsd.org>
Cc:        svn-doc-head@freebsd.org, svn-doc-all@freebsd.org, doc-committers@freebsd.org, Isabell Long <issyl0@freebsd.org>
Subject:   Re: svn commit: r39468 - head/en_US.ISO8859-1/books/handbook/ports
Message-ID:  <alpine.GSO.1.10.1208291337200.861@multics.mit.edu>
In-Reply-To: <20120829171741.GA5967@glenbarber.us>
References:  <201208291429.q7TET3kL060721@svn.freebsd.org> <alpine.GSO.1.10.1208291302440.861@multics.mit.edu> <20120829171741.GA5967@glenbarber.us>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 29 Aug 2012, Glen Barber wrote:

>>> +
>>> +	  <para>When installing a port, using only <command>make
>>> +	      <maketarget>install</maketarget></command> 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 <command>make
>>> +	      <maketarget>config-recursive</maketarget></command> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.1.10.1208291337200.861>